When compiling source code with webpack, users can generate a JSON file containing statistics about modules. These statistics can be used to analyze an application's dependency graph as well as to optimize compilation speed. The file is typically generated with the following CLI command:
webpack --profile --json > compilation-stats.json
The --json > compilation-stats.json
flag indicates to webpack that it should emit the compilation-stats.json
containing the dependency graph and various other build information. Typically, the --profile
flag is also added so that a profile
section is added to each modules
object containing module-specific compilation stats.
The top-level structure of the output JSON file is fairly straightforward but there are a few nested data structures as well. Each nested structure has a dedicated section below to make this document more consumable. Note that you can click links within the top-level structure below to jump to relevant sections and documentation:
{
'version': '1.4.13', // Version of webpack used for the compilation
'hash': '11593e3b3ac85436984a', // Compilation specific hash
'time': 2469, // Compilation time in milliseconds
'filteredModules': 0, // A count of excluded modules when exclude
is passed to the toJson
method
'outputPath': '/', // path to webpack output directory
'assetsByChunkName': {
// Chunk name to emitted asset(s) mapping
'main': 'web.js?h=11593e3b3ac85436984a',
'named-chunk': 'named-chunk.web.js',
'other-chunk': [
'other-chunk.js',
'other-chunk.css'
]
},
'assets': [
// A list of asset objects
],
'chunks': [
// A list of chunk objects
],
'modules': [
// A list of module objects
],
'errors': [
// A list of error strings
],
'warnings': [
// A list of warning strings
]
}
Each assets
object represents an output
file emitted from the compilation. They all follow a similar structure:
{
'chunkNames': [], // The chunks this asset contains
'chunks': [ 10, 6 ], // The chunk IDs this asset contains
'emitted': true, // Indicates whether or not the asset made it to the output
directory
'name': '10.web.js', // The output
filename
'size': 1058, // The size of the file in bytes
'info': {
'immutable': true, // A flag telling whether the asset can be long term cached (contains a hash)
'size': 1058, // The size in bytes, only becomes available after asset has been emitted
'development': true, // A flag telling whether the asset is only used for development and doesn't count towards user-facing assets
'hotModuleReplacement': true // A flag telling whether the asset ships data for updating an existing application (HMR)
}
}
Asset's
info
property is available since webpack v4.40.0
Each chunks
object represents a group of modules known as a chunk. Each object follows the following structure:
{
"entry": true, // Indicates whether or not the chunk contains the webpack runtime
"files": [
// An array of filename strings that contain this chunk
],
"filteredModules": 0, // See the description in the top-level structure above
"id": 0, // The ID of this chunk
"initial": true, // Indicates whether this chunk is loaded on initial page load or on demand
"modules": [
// A list of module objects
"web.js?h=11593e3b3ac85436984a"
],
"names": [
// An list of chunk names contained within this chunk
],
"origins": [
// See the description below...
],
"parents": [], // Parent chunk IDs
"rendered": true, // Indicates whether or not the chunk went through Code Generation
"size": 188057 // Chunk size in bytes
}
The chunks
object will also contain a list of origins
describing how the given chunk originated. Each origins
object follows the following schema:
{
"loc": "", // Lines of code that generated this chunk
"module": "(webpack)\test\browsertest\lib\index.web.js", // Path to the module
"moduleId": 0, // The ID of the module
"moduleIdentifier": "(webpack)\test\browsertest\lib\index.web.js", // Path to the module
"moduleName": "./lib/index.web.js", // Relative path to the module
"name": "main", // The name of the chunk
"reasons": [
// A list of the same reasons
found in module objects
]
}
What good would these statistics be without some description of the compiled application's actual modules? Each module in the dependency graph is represented by the following structure:
{
"assets": [
// A list of asset objects
],
"built": true, // Indicates that the module went through Loaders, Parsing, and Code Generation
"cacheable": true, // Whether or not this module is cacheable
"chunks": [
// IDs of chunks that contain this module
],
"errors": 0, // Number of errors when resolving or processing the module
"failed": false, // Whether or not compilation failed on this module
"id": 0, // The ID of the module (analogous to module.id
)
"identifier": "(webpack)\test\browsertest\lib\index.web.js", // A unique ID used internally
"name": "./lib/index.web.js", // Path to the actual file
"optional": false, // All requests to this module are with try... catch
blocks (irrelevant with ESM)
"prefetched": false, // Indicates whether or not the module was prefetched
"profile": {
// Module specific compilation stats corresponding to the --profile
flag (in milliseconds)
"building": 73, // Loading and parsing
"dependencies": 242, // Building dependencies
"factory": 11 // Resolving dependencies
},
"reasons": [
// See the description below...
],
"size": 3593, // Estimated size of the module in bytes
"source": "// Should not break it...
if(typeof...", // The stringified raw source
"warnings": 0 // Number of warnings when resolving or processing the module
}
Every module also contains a list of reasons
objects describing why that module was included in the dependency graph. Each "reason" is similar to the origins
seen above in the chunk objects section:
{
"loc": "33:24-93", // Lines of code that caused the module to be included
"module": "./lib/index.web.js", // Relative path to the module based on context
"moduleId": 0, // The ID of the module
"moduleIdentifier": "(webpack)\test\browsertest\lib\index.web.js", // Path to the module
"moduleName": "./lib/index.web.js", // A more readable name for the module (used for "pretty-printing")
"type": "require.context", // The type of request used
"userRequest": "../../cases" // Raw string used for the import
or require
request
}
The errors
and warnings
properties each contain a list of strings. Each string contains a message and stack trace:
../cases/parsing/browserify/index.js
Critical dependencies:
2:114-121 This seem to be a pre-built javascript file. Even while this is possible, it's not recommended. Try to require to original source to get better results.
@ ../cases/parsing/browserify/index.js 2:114-121
Note that the stack traces are removed when
errorDetails: false
is passed to thetoJson
method. TheerrorDetails
option is set totrue
by default.