Multiple webpack instances on the same page break code splitting

[matt-gadd]

At the moment, if you put say 2 separate webpack bundles on the page, both that require something out of the commons chuck (or a code split) - webpack seems to merge/munge the module maps across both bundles, this results in actually loading the wrong module.

Webpack alarmingly uses a known function on the window to provide its code splitting/loading capability, which collides if multiple instances are used. This can fortunately be configured in the webpack.config so we can avoid this.

Here is the excerpt from the Webpack docs at https://webpack.js.org/configuration/output/:

output.jsonpFunction

Only used when target is web, which uses JSONP for loading on-demand chunks.

A JSONP function name used to asynchronously load chunks or join multiple initial chunks (CommonsChunkPlugin, AggressiveSplittingPlugin).

This needs to be changed if multiple webpack runtimes (from different compilation) are used on the same webpage.

[mwistrand]

When you say that both builds "require something out of the commons chuck (or a code split)", do you mean that they both require from two different commons chunks? I'm assuming so, since if they both pull from the same chunk, then the common jsonpFunction should not be problem.

In any case, the default name is webpackJsonp, so something like dojoWebpackJsonp should be sufficient to avoid collisions. Since there may be scenarios in which using a different jsonpFunction is undesirable, an additional option could be introduced to turn this off; if the user needs to use a customize the jsonpFunction beyond those two values (dojoWebpackJsonp or webpackJsonp), I'm inclined to think the eject should be used.

I have a POC on my fork; if this is the route we want to go, I can open a PR.

[matt-gadd]

Yes they are 2 separate builds with separate commons chunks. The naming to a fixed name in this scenario like dojoWebpackJson will not suffice. I tend to disagree on the final point, I think in most scenarios anything that is not produced in the same build would be undesirable to have the same jsonp function name? i.e. How do we know the compatibility across them?

[matt-gadd]

re: compatibility, if we do keep one global jsonp name, should we then hash the chunks instead?

[mwistrand]

Of course, you're right that a single dojoWebpackJsonp function won't work once more than a single build is compiled with cli-build-webpack. With regard to using the same jsonpFunction across builds, my line of thinking was around organizations that have several applications that are built separately but rely on a common code base, but that's really the realm of the DllPlugin. In that case, which option seems better in the long run: a custom jsonpFunction that defaults to dojoWebpackJsonp, or some sort of buildIndex that is mapped to a dojoWebpackJsonp${buildIndex} function name?

[kitsonk]

This is flagged as expedited... is this still the sort of blocker that it is flagged as, or is it really just a backlog item now?

[kitsonk]

This does not appear to be a blocking issue anymore according to @tomdye and should be looked at in due course.

[mwistrand]

I'm still getting caught up on the current state of cli-build-webpack, but do we have a means of providing a name to the build that could potentially be used in the jsonpFunction (in the same way that output.library is)? Alternatively, another (overkill?) solution might be to generate a unique ID for each build:

jsonpFunction: `dojoJsonpWebpack_${uuid().replace(/-/g, '')}`;

[matt-gadd]

I'd be reluctant to add more user config in cli-build. How about we use the package name from the package.json, this will guarantee it's mostly unique, but better than a uuid as it will be common across builds.