[v5 migration] Cache group "default" conflicts with existing chunk.

[yellow1912]

Bug report

What is the current behavior?

I'm not exactly sure if this is a bug, so please let me know if I should move this somewhere else. I'm in the process of moving webpack from v4 to v5, and I run into the following error:

In my webpack config file, I use the below config:

optimization: {
        runtimeChunk: {
            name: "runtime"
        },
        splitChunks: {
            chunks: 'all',
            name: 'split'
        }
    }

I want to make sure everything is put into a single file. I know it's not optimized but the size of the file is not very big, and it makes including these files much easier with our legacy app.

The above config worked well for v4, but in v5 I got the following error:

ERROR in SplitChunksPlugin
Cache group "default" conflicts with existing chunk.
Both have the same name "split" and existing chunk is not a parent of the selected modules.
Use a different name for the cache group or make sure that the existing chunk is a parent (e. g. via dependsOn).
HINT: You can omit "name" to automatically create a name.
BREAKING CHANGE: webpack < 5 used to allow to use an entrypoint as splitChunk. This is no longer allowed when the entrypoint is not a parent of the selected modules.
Remove this entrypoint and add modules to cache group's 'test' instead. If you need modules to be evaluated on startup, add them to the existing entrypoints (make them arrays). See migration guide of more info.

I'm not quite sure how to fix it. The document didn't say if there is anything else I should do when I specify the name (https://webpack.js.org/plugins/split-chunks-plugin/#splitchunksname)

If the current behavior is a bug, please provide the steps to reproduce.

I believe the configuration provided is enough, but if more information is needed please let me know:

optimization: {
        runtimeChunk: {
            name: "runtime"
        },
        splitChunks: {
            chunks: 'all',
            name: 'split'
        }
    }

What is the expected behavior?

I expect 1 single split file generated just like in v4, without any error.

Other relevant information: webpack version: 5.44.0 (cli: 4.7.2) Node.js version: v14.17.0 Operating System: Windows 10 Additional tools: none

Edit 1: Following the comment here https://github.com/vercel/next.js/discussions/18339, if I add the following config to splitChunks then it works:

cacheGroups: {
                default: false
            }

I don't know how splitchunks work internally, but my guess (looking at the default configs on https://webpack.js.org/plugins/split-chunks-plugin/#splitchunksname) is that you have 2 cache groups: defaultVendor and default. Somehow these cache groups, due to the shared name "split" defined lead to certain conflicts? This looks like a bug because if the document clearly says that you can use the same name to force a single splitchunk file then this kind of conflict should be handled internally?

[webpack-bot]

For maintainers only:

• [ ] webpack-4
• [ ] webpack-5
• [ ] bug
• [ ] critical-bug
• [ ] enhancement
• [ ] documentation
• [ ] performance
• [ ] dependencies
• [ ] question

[chenxsan]

Unfortunately I'm not able to reproduce with the configuration you provided:

Could you share more? It would be much better if you can provide a reproducible repository.

[gtempesta]

I had a very similar error message. I think it was caused by two modules in the same directory being dynamically imported in different parts of the code. One of the two imports didn't have a webpackChunkName magic comment, so the solution was to add the name in the import that didn't have it.

if (!window.prod) {
  import('@/chunks/staff' /* webpackChunkName: "staff" */).then(() => {});
}

[Bubbleinpit]

From https://webpack.js.org/migrate/5/ :

Reconsider optimization.splitChunks:

It's recommended to use either the defaults or optimization.splitChunks: { chunks: 'all' }. When using a custom configuration, drop name: false and replace name: string | function with idHint: string | function. It was possible to turn off the defaults by setting optimization.splitChunks.cacheGroups: { default: false, vendors: false }. We don't recommend doing this, but if you really want to get the same effect in webpack 5: optimization.splitChunks.cacheGroups: { default: false, defaultVendors: false }.

So I think you should replace your name: "split" with idHint: "split", also for the name: "runtime"

[SaqlainYounas]

whats the resolution to this issue?

[natali55]

Same question: whats the resolution to this issue?

[woowalker]

same issue, finally i figure out that it was caused by amcharts4, amcharts4 alse split xlsx, conflict with my project, i have to rename my chunk name to xlsx0185, then the error gone.

[gtempesta]

If someone doesn't have the constraint that the OP has (having just one file for the vendors), after a series of errors like these I've figured out that the best outcome is to let Webpack give the names to the chunks. On the other hand, the runtime can either have a dynamic or a static name, I've never had issues with that.

In my case the name is not a problem, because I'm generating a manifest file and I link the scripts in the page with some custom code that reads the "entrypoints" key in the manifest.

So if you don't mind having generated/unpredictable names, the solution is a configuration like this:

optimization: {
  splitChunks: {
    chunks: 'all',
  },
  runtimeChunk: {
    // this can even be static, like 'runtime' or 'runtime-app'
    name: entrypoint => `runtime-${entrypoint.name}`,
  },
},

As a further explanation, I've found a couple of comments in my Webpack configuration that might help you:

1. Avoid giving a static name to the vendor chunk, as it forces all the code from node_modules into a single chunk, while if we don't give it a name there can be multiple chunks with the code from external libraries, based on where the code is needed (for example if a library is only needed in a dynamically loaded chunk, the library is only loaded with that chunk)
2. Avoid specifying a dynamic name to the other chunks as it may force code from different modules into the same chunk (if for some reason the dynamic name of two distinct chunks happens to be the same)