reuseExistingChunk option does not respect webpackChunkName

Bug report

What is the current behavior?

Webpack 5 does not seem to respect the splitChunks.cacheGroups.{cacheGroup}.reuseExistingChunk option when handling chunks named with webpackChunkName, resulting in the custom name being overridden by the cache group name.

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

See my minimal reproduction repo here showcasing example builds in v4 and v5. v4 behaves as expected while v5 (from what I can tell) incorrectly names one of the async chunks.

The configs in webpack-4 and webpack-5 should be identical besides a few version-specific changes around cleaning and disabling default cache groups. @formatjs/intl-datetimeformat is used as an arbitrary example to illustrate dynamically importing two modules, one of which meets the cache group size threshold.

What is the expected behavior?

Webpack v5 matches the previous behavior from v4 where reuseExistingChunk: true results in named chunks not being affected by split chunk cache groups (even if they satisfy a group’s test). In the case of the specific example above, both async chunks should be named with their custom webpackChunkNames rather than one using the lib cache group hash.

I may be misinterpreting the expected behavior here, though it does seem like there is a change between v4 and v5. Perhaps I missed something in the migration guide?

Other relevant information: webpack version: 5.36.2 (4.46.0 when comparing with webpack 4 behavior) Node.js version: 14.16.0 Operating System: macOS 10.15.7

[alexander-akait]

Yep, there is no bugs, reuseExistingChunk means you already have name for chunk(s), so naming will not work here

[chrissantamaria]

@alexander-akait sounds good! Ended up finding a workaround for my specific use case but this example helps show some of the differences in Webpack 5. This doesn’t look like a bug so I’m okay closing this issue if you’d like.