Source maps missing for non-entry chunks after rebuild

[richvdh]

Do you want to request a feature or report a bug?
Looks like a bug.

What is the current behavior?
Using webpack-dev-server, on a rebuild, non-entry chunks are regenerated with a new compliation hash in the filename, but the sourcemaps are not regenerated.

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

1. In a project using code-splitting:
2. In config:

• Include [hash] in output.chunkFilename
• set devtool: 'source'

3. Start webpack-dev-server
4. Modify content of entry chunk
5. Try to load source-map for secondary chunk.

See https://github.com/richvdh/webpack-bug-demo for a minimal repo demonstrating this problem.

What is the expected behavior?
Webpack should serve the sourcemap for the secondary chunk with the new filename.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
Webpack 1.14.0; webpack-dev-server 1.16.2; node 5.0.0; Linux.

[richvdh]

The output from the rebuild is something like:

webpack: bundle is now INVALID.
Hash: 1b1122737f7c1628ed4f
Version: webpack 1.14.0
Time: 19ms
                    Asset       Size  Chunks             Chunk Names
                bundle.js    3.96 kB       0  [emitted]  main
1b1122737f7c1628ed4f/1.js  117 bytes       1  [emitted]  
            bundle.js.map    4.02 kB       0  [emitted]  main
chunk    {0} bundle.js, bundle.js.map (main) 165 bytes [rendered]
    [0] ./main.js 165 bytes {0} [built]
chunk    {1} 1b1122737f7c1628ed4f/1.js, c62c1f97e3af83189928/1.js, c62c1f97e3af83189928/1.js.map 32 bytes {0}
     + 1 hidden modules
webpack: bundle is now VALID.

Note that chunk 1 is being generated for both the old and new hashes (c62c1f97e3af83189928 and 1b1122737f7c1628ed4f, respectively), but the sourcemap is only generated for the old hash.

[sokra]

I have a fix, but no time to write tests for this currently.

[sokra]

Using [hash] in chunkFilename is maybe a bad choice...

[richvdh]

Using [hash] in chunkFilename is maybe a bad choice...

I'd be interested to hear if you have better suggestions. The thinking behind putting [hash] there went as follows:

• When we deploy a new version of our application to our production server, we want people using the old version of the app not to see errors.
• That means we need to keep the old versions of the chunks available as well as the new ones.
• But we don't want our production server to fill up with hundreds of old chunk files.
• By putting [hash] in the filenames, we can clean out directories corresponding to old versions of the app once we are satisfied that nobody is using them.

[richvdh]

tbh we worked around this by using a hardcoded string instead of [hash] when running the dev server - but obviously it's preferable to minimise differences between production and dev, and this took me somewhat by surprise.

[sokra]

[chunkhash] is the better option, as it reused old cached chunks when only a small part of the app changes.

[sokra]

Anyway, you should be able to do it the [hash] way. If you want to you can finish my PR with tests and we can merge it.