Chunk ids can change in production causing updated file contents #461
Comments
|
It seems to match what I observed in #361 (comment) :) |
|
See #462 |
weaverryan
added a commit
that referenced
this issue
Nov 29, 2018
…ing too often. (weaverryan) This PR was squashed before being merged into the master branch (closes #462). Discussion ---------- Always used named chunks AND prevent split chunks from changing too often. Fixes #461 But, this does not expose the entry names internally in the code (as these are used instead of auto-incremet ids). I don't think there's a way around that. Also, I'm still tracking down a somewhat related but that causes a related issue (meaningless id's changing in generated code) under very specific conditions. In fact, you can see it in this test case just by changing all the 3 of the entries to an array - e.g. ```js config.addEntry('main1', ['./js/code_splitting']); if (includeExtraEntry) { config.addEntry('main2', ['./js/eslint']); } config.addEntry('main3', ['./js/no_require']); ``` That doesn't need to block this PR, but I need to figure out the issue (it's Webpack behavior) and see if it affects versioning (i.e. if the contents change but the file hashes do NOT change, this is a BIG problem, otherwise, it's more of a minor, performance problem as filenames would just be changing too often). Commits ------- a8b6725 Making how the splitting works more consistent 4de5536 Fixing tests 13e07c6 linking to issue 7c96476 Fixing a bug where split filenames might change too often a426b8c Always used named chunks to avoid caching problems
weaverryan
added a commit
that referenced
this issue
Nov 29, 2018
This PR was squashed before being merged into the master branch (closes #463). Discussion ---------- Using contenthash instead of chunkhash Since Webpack 4.3.0, a `[contenthash]` has existed, which is the [recommended way](https://webpack.js.org/guides/caching/#output-filenames) of versioning your filenames. Previously, we used a special plugin that gave us a `chunkhash`, which worked around issues with hash changing unnecessarily. However, `chunkhash` actually created a bug - in #461, some chunk id's change unnecessarily. That's bad for caching, but the *real* problem was that `[chunkhash]` did not change, and so the filenames did not change. The filenames DO change with `[contenthash]`. Commits ------- 3797cba Using contenthash instead of chunkhash
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi guys!
I just finished hunting down a deep bug in Webpack / Encore. Here are the details:
A) When
mode: production, Webpack sets theoptimization.namedChunksoption tofalse. This is an internal key that's used in the generated files and when this is set to false, it uses incrementing integers.B) When you make certain changes (e.g. add a new entry), it may cause the chunk name for a specific chunk to change - e.g. 19 becomes 20. But this means that any files that depend on this module will change - a little
19inside these files will be changed to20, even if nothing else in that file changed.C) To make matters worse, this updated file contents does NOT cause the file's hash to change with versioning. The result is that the same filename is built, but with different contents.
The bug is described in Webpack here: webpack/webpack#8354 - and will likely be fixed in Webpack 5 - webpack/webpack#8374
I believe that this is only a problem if you use
.enableSingleRuntimeChunk()(which is the default in a new app) because this causes each file to be wrapped in code like this:Where that
[6]is the chunk id that may change. If you do not use the single runtime chunk, the files are not wrapped with this.I'll open a PR shortly to fix this.
The text was updated successfully, but these errors were encountered: