Gathering detailed insights and metrics for webpack-after-chunk-hash-plugin
Gathering detailed insights and metrics for webpack-after-chunk-hash-plugin
Gathering detailed insights and metrics for webpack-after-chunk-hash-plugin
Gathering detailed insights and metrics for webpack-after-chunk-hash-plugin
npm install webpack-after-chunk-hash-plugin
Typescript
Module System
Node Version
NPM Version
70.3
Supply Chain
98.3
Quality
74.7
Maintenance
100
Vulnerability
100
License
JavaScript (100%)
Total Downloads
19,679
Last Day
1
Last Week
6
Last Month
33
Last Year
374
5 Stars
3 Commits
1 Forks
3 Watching
1 Branches
1 Contributors
Minified
Minified + Gzipped
Latest Version
1.0.0
Package Id
webpack-after-chunk-hash-plugin@1.0.0
Size
17.31 kB
NPM Version
3.10.10
Node Version
6.10.3
Cumulative downloads
Total Downloads
Last day
0%
1
Compared to previous day
Last week
-33.3%
6
Compared to previous week
Last month
83.3%
33
Compared to previous month
Last year
-85.8%
374
Compared to previous year
A webpack plugin to rename chunks to incorporate their true hashes, after the chunks have been emitted, regardless of their import order, or any other non deterministic state.
After setting up my webpack config file to chunk my application and product a manifest.js file via the CommonChunksPlugin, I was finding that the hashes in the filenames generated in the manifest.js file were different to the ones webpack was trying to call. Other developers have been running into the same problem.
My simplified webpack config:
1module.exports = { 2 entry: 'index.js', 3 output: { 4 path: path.resolve(__dirname, 'public', 'dist'), 5 6 // all chunks should be fingerprinted with their hash 7 filename: '[name].[chunkhash:7].js', 8 chunkFilename: '[name].[chunkhash:7].js' 9 }, 10 11 resolve: { 12 extensions: [], 13 ... 14 }, 15 16 module: { 17 rules: [ 18 ... 19 ] 20 }, 21 22 plugins: [ 23 // make sure we're using MD5 to generate hashes 24 new WebpackMd5Hash(), 25 26 // put all node modules into a vendor chunk 27 new webpack.optimize.CommonsChunkPlugin({ 28 name: 'vendor', 29 minChunks: function(module) { 30 return /node_modules/.test(module.resource); 31 } 32 }), 33 34 // and separate webpack manifest into separate file further, so we can include it directly on the HTML page 35 new webpack.optimize.CommonsChunkPlugin('manifest') 36 ] 37}
When running webpack, I was getting the following output [1]:
chunk-details.d86abc7.js 708 kB 1 [emitted] [big] chunk-details
chunk-home.3ba4f8b.js 296 kB 2 [emitted] [big] chunk-home
vendor.eb1350c.js 2.97 MB 3 [emitted] [big] vendor
manifest.d41d8cd.js 6.66 kB 4 [emitted] manifest
On inspecting how webpack is producing the chunk files, I see the following:
...
module.exports = exports['default'];
/***/ }),
/* 2 */,
/* 3 */
/***/ (function(module, exports, __webpack_require__) {
"use strict";
// further down in the code ...
var _someModule = __webpack_require__(2)
Here, webpack is de-duplicating my imports so the same module isn't bundled into the chunks multiple times.
When webpack needs a reference to this module, it will call it using __webpack_require__(2)
or __webpack_require__(3)
This is where our bug comes in - when changing some code in a chunk, and rerunning webpack, I was still seeing the same output for the non modified chunks as shown in [1] (which is expected), however, the webpack output has now changed slightly:
...
module.exports = exports['default'];
/***/ }),
/* 2 */,
/* 3 */
/***/ (function(module, exports, __webpack_require__) {
"use strict";
// further down in the code ...
var _someModule = __webpack_require__(3) // this require number is different!
Although webpack is still trying to get a reference to the module I want, it is using a different module chunk id to try and do so.
When computing chunks' hashes, webpack does so only on the contents of the chunk, hence if nothing changes in that chunk, the same chunk hash should be produced.
When webpack compiled all of the necessary modules into a single file, it seems to do so in a non deterministic way, maybe because it is trying to promote the most used chunks to the top for optimization purposes.
This means that chunks which haven't changed will still be trying to reference the module using __webpack_require__(2)
whereas the newly changed chunk may try and access it as __webpack_require__(3)
.
Since a chunk only has one module chunk id, one of those calls will fail.
Since hashes are only computed based on the contents of the module, and not the final file created, this means that even though the new chunk webpack generates will correctly try referencing __webpack_require__(3)
, it will have the same name final name as what was output before. To summarize:
Compilation | File generated | Webpack call |
---|---|---|
1 | vendor.eb1350c.js | __webpack_require__(2) |
2 | vendor.eb1350c.js | __webpack_require__(3) |
Due to caching, our browser won't try downloading the changed file due to it having the same name. Hence our call to the required chunk file will fail - it's still using the file which is trying to search for 2
instead of 3
HashedModuleIdsPlugin
to the rescue?The webpack.HashedModuleIdsPlugin
replaces the module chunk ids with a short string, hence always calling the webpack module using the same string. Our webpack code now looks like the following:
module.exports = exports['default'];
/***/ }),
/***/ "V7Hl":
/***/ (function(module, exports) {
"use strict";
// further down in the code ...
var _someModule = __webpack_require__("V7Hl")
This seems to work in most use cases, but not all. Sometimes untouched chunks will still try referencing an old hashed module id, whereas the changed chunk will reference the new one. That means we still run into the same problem as before.
AfterChunkHashPlugin
AfterChunkHashPlugin waits until the final chunks have all been output and written to disk, and then recomputes the hashes of the files created, and updates all references accordingly.
It's not an ideal solution given we're updating files which have already been written to disk, but I've been using this in production for a couple of months now on a large site, and it has seemed to solve our issue of non deterministic hashing.
This forces the fingerprints of the files created to update, and hence the browser cache is bust, and is forced to download the latest file which has the updated references.
Install using npm
or yarn
1npm install webpack-after-chunk-hash-plugin --save-dev 2yarn add webpack-after-chunk-hash-plugin --dev
In your webpack.config.js
file:
1const AfterChunkHashPlugin = require('webpack-after-chunk-hash-plugin'); 2 3module.exports = { 4 ... 5 plugins: [ 6 new AfterChunkHashPlugin(opts) 7 ] 8}
The AfterChunkHashPlugin accepts an object of options with the following attributes:
1new AfterChunkHashPlugin({
2 manifestJsonName: 'manifest.json'
3})
manifestJsonName
the name of the manifest json file you are using - the plugin will rename the references in this file for you too.No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 0/2 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
23 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-12-23
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More