I’m submitting a bug report
Please tell us about your environment:
I have a scenario where I’m using webpack to create multiple JS bundles. Each bundle uses the CommonsChunkPlugin to aggregate shared code, and each has its own webpack.config.js. On some pages, only one of these bundles will be included, but on other pages we end up including both bundles.
In this latter case, I believe we end up with multiple webpack runtimes (one in each of our shared chunks), and it seems they do not play well with each other.
In particular, the second bundle’s entry file ends up trying to use the first bundle’s runtime to require modules, which results in it loading modules from the first bundle when it intends to load modules from the second bundle.
In case this is all hard to understand, I’ve created a simple repo that repros the buggy behavior.
This repro creates two different sets of bundles. Each bundle has two entry points, and some common code. We then have an html page that serves one of the two entry points from each.
What I would expect to happen:
We load one/A1.js, which requires one/shared.js and logs “A1” and “shared A”.
We then load two/B1.js, which requires two/shared.js and logs “B1” and “shared B”.
What actually happens
We load one/A1.js, which requires one/shared.js and logs “A1” and “shared A”. (expected)
We load two/B1.js, which requires one/shared.js (unexpected) and logs “B1” and “shared A”. We then reenter the main chunk in B1, require two/shared.js, and log “B1” and “shared B”
My (limited) understanding of what’s happening is that B1 sees that we already have a webpack runtime, and decides to use that to load shared. It looks for chunk “1”, and since common_A’s runtime has mapped 1 to one/shared.js, we load that. For reasons I don’t fully understand we then load again with common_B’s runtime, which has mapped 1 to two/shared.js