There's this flag reuseExistingChunk of SplitChunksPlugin which, when true, moves a chunk up to the parent cache group to avoid outputting duplicated code, and doesn't generate any file for the source chunk itself. This conflicts with the behaviour of flushChunkNames() since it won't look for chunk dependencies inside stats.namedChunkGroups if it's not inside stats.chunks in the first place, but it should. More people might face this same issue because it's the default behaviour of splitChunks.cacheGroups.defaults.
To be honest, I'm not 100% sure if it's because of reuseExistingChunk. Maybe this is just the expected normal behaviour.
Scenarios:
User has defined a cache group but it only encompasses one module, meaning the group chunk will be generated but not a chunk for the source module
User has defined a cache group but, because of restrictions provided by minChunks, minSize, maxSize or any other config parameter, Webpack ends up moving a module to the parent chunk
There's this flag
reuseExistingChunkof SplitChunksPlugin which, whentrue, moves a chunk up to the parent cache group to avoid outputting duplicated code, and doesn't generate any file for the source chunk itself. This conflicts with the behaviour offlushChunkNames()since it won't look for chunk dependencies insidestats.namedChunkGroupsif it's not insidestats.chunksin the first place, but it should. More people might face this same issue because it's the default behaviour ofsplitChunks.cacheGroups.defaults.To be honest, I'm not 100% sure if it's because of
reuseExistingChunk. Maybe this is just the expected normal behaviour.Scenarios:
Related code fragment: https://github.com/faceyspacey/webpack-flush-chunks/blob/b3534a330096b40912a0735e518b047563aa61bf/src/flushChunks.js#L233-L238