-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doesn't seem to fully solve the problem #11
Comments
Util that moment (Before you fix it). Suppose you have subtree If you just copy folder
And changing top requires apparently in one module file of chunkB which means change depended module file content, hence output a different chunk-hash. |
exactly
I did not add a new webpack config entry. Webpack does automatically creates a new chunk because I'm using However, the chunks were not identical since they are dependent of different modules that are used in those chunks, only. |
Unfortunately, the chunk hash calculated by this plugin is "too stable".
Today I added added a large subtree to my application (duplicated a subdirectory to use it as a basis for something new). This subtree got it's own Webpack "chunk", as many parts of the application are loaded on-demand.
Before the change one of the Webpack chunks was named "3-chunk-0-53-48686df03dc821ceba28b976c-en.js". After the change, a new chunk with identical name was created, but with completely different content.
This caused the Webpack runtime to request
chunkId
"12", which simply didn't exist.I have no clue what could be the reason for this and what is necessary to reproduce it. Anyway, the build was sensitive to the order of my
require
s. Just switching one of the top requires apparently fixed the problem (switching back revealed the problem again).Luckily, changing the
seed
option to a different value allows me to avoid the real problem, but obviously it's not the "solution" I would hope for.This description probably doesn't contain enough information to track down the problem (sorry, can't provide anything more useful) - but it's probably good to take note of it...
The text was updated successfully, but these errors were encountered: