Compilation chunks can have duplicate ids

[jdelStrother]

Bug report

(I think this is a bug. It's possible it's a feature I don't yet understand.)

What is the current behavior?

When using the split chunks plugin, the resulting compilation chunks sometimes have duplicate ids. For example, I added this debugging hook to my webpack config:

  compiler.hooks.afterEmit.tap("log-dupe-chunks", function(compilation) {
    let chunks = compilation.chunks;
    let chunkIds = chunks.map(c => c.id);
    let dupeChunks = chunks
      .filter(c => chunkIds.filter(i => i === c.id).length > 1)
      .map(c =>
        pick(c, ["id", "ids", "debugId", "name", "entryModule", "files", "rendered", "hash", "contentHash", "renderedHash", "chunkReason", "extraAsync"])
      );
    if (dupeChunks.length) {
      console.log(dupeChunks);
    }
  });

Resulting in this output:

[ { id: 'vendors~markdownediting~uploader',
    ids: [ 'vendors~markdownediting~uploader' ],
    debugId: 1011,
    name: 'lazy_store',
    entryModule: undefined,
    files:
     [ 'lazy_store.8122ea9e5a55db822e44.js',
       'lazy_store.8122ea9e5a55db822e44.js.map' ],
    rendered: true,
    hash: '8122ea9e5a55db822e44da03c4fa5547',
    contentHash: { javascript: '721f86d9054aaadb11d1' },
    renderedHash: '8122ea9e5a55db822e44',
    chunkReason: undefined,
    extraAsync: false },
  { id: 'vendors~markdownediting~uploader',
    ids: [ 'vendors~markdownediting~uploader' ],
    debugId: 1026,
    name: 'vendors~markdownediting~uploader',
    entryModule: undefined,
    files:
     [ 'vendors~markdownediting~uploader.bd57c5c4595c93582c8b.js',
       'vendors~markdownediting~uploader.bd57c5c4595c93582c8b.js.map' ],
    rendered: true,
    hash: 'bd57c5c4595c93582c8b9e692da052d0',
    contentHash: { javascript: 'c9f2f1d06758f3a354b1' },
    renderedHash: 'bd57c5c4595c93582c8b',
    chunkReason: 'split chunk (cache group: vendors) (name: vendors~markdownediting~uploader)',
    extraAsync: false } ]

Shouldn't that first chunk have an id of lazy_store ?

I've only seen the duplicate chunk ids where one of the chunks is my code, the other chunk is vendor/node_modules code (see the cache group: vendors bit).

I've also only seen this happen when using recordsPath. If I delete my webpack records & re-build, all the chunk ids are unique.

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

Sorry, I'm really struggling to narrow this down. It seems to come and go at the whim of whatever heuristics drive SplitChunksPlugin. If someone can confirm this is a bug and it's not immediately obvious why it happens, I'll try harder.

What is the expected behavior?

Presumably all compilation chunks should have unique ids?

Other relevant information:
webpack version: 4.6.0
Node.js version: 8.11.1
Operating System: Docker with node:8.11-alpine

I'm using https://github.com/GProst/webpack-clean-obsolete-chunks, which expects chunks to have unique ids, and ends up accidentally deleting files when they don't. If it turns out that chunks are allowed to have duplicate ids, I'll submit a fix to that.

[sokra]

This looks like a bug.

[jdelStrother]

Thanks for the rapid fix. I'm going to leave it running locally and see if it surfaces any other problems, but so far it looks promising.

[jdelStrother]

@sokra Is it intentional that with this change, ids from HashedModuleIdsPlugin are no longer recorded? I used to have several hundred lines in my webpack records.json looking something like this:

{
  "modules": {
    "byIdentifier": {
      "node_modules/lodash/_objectToString.js": "+66z",
      "node_modules/react-dom/lib/getVendorPrefixedEventName.js": "+KdC",
      "node_modules/babel-loader/lib/index.js??ref--1!assets/javascripts/lib/page_ready.js": "+PKl",
      "node_modules/css-loader/index.js?{\"modules\":true,\"importLoaders\":1,\"localIdentName\":\"[name]__[local]___[hash:base64:5]\"}!node_modules/postcss-loader/lib/index.js?{}!assets/javascripts/components/uploader/Marker/Marker.css": "+TPF",
      "node_modules/react-dom/lib/accumulateInto.js": "+VAZ",
      "node_modules/lodash/throttle.js": "+X65",
      "node_modules/raw-loader/index.js!node_modules/trumbowyg/dist/ui/icons.svg": "+XyB",
      "node_modules/react-dom/lib/getEventCharCode.js": "+cCx",
      "node_modules/react-dom/lib/CSSProperty.js": "+ktn",
      "node_modules/babel-loader/lib/index.js??ref--1!assets/javascripts/stores/draggable_list_store.js": "+zBU",
      "node_modules/babel-loader/lib/index.js??ref--1!assets/javascripts/components/admin/region_category_picker.jsx": "/5SY",
      "node_modules/react-dom/lib/ReactNodeTypes.js": "/762",
      "node_modules/babel-loader/lib/index.js??ref--1!assets/javascripts/components/embed_editor/preview_size_toolbar.jsx": "/EV3",
      "node_modules/babel-loader/lib/index.js??ref--1!assets/javascripts/components/uploader/TimeInput/validate.js": "/SFD",
      "node_modules/react-dom/lib/ReactDOMInvalidARIAHook.js": "/SFT",
      "node_modules/react-dom/lib/setTextContent.js": "/bNP",

but since their id isn't a number, they're all gone.

[sokra]

@jdelStrother It's a hash of the key, so no need to store them as they can be recreated.