Webpack 5 worker import fails with "chunks: 'all'" + [contenthash] in output filename

[wh1t3cAt1k]

Bug report

What is the current behavior?

Worker import started producing a script loading error as soon as I added [contenthash] into the output filename.

I see a strange 404 error in the console for a non-existent chunk script with a strange path (note the .undefined.js postfix):

https://localhost/addin/src_functions_parallelism_caching_passport-worker_ts-_36b50.undefined.js

Where does this .undefined.js part come from? Does it give anyone any idea?

The actual filename of the chunk that does exist after compilation is src_functions_parallelism_caching_passport-worker_ts-_36b50.8ba2df42b53ad688d69d.js - instead of undefined there's a proper content hash.

Relevant bits of configuration:

    output: {
        path: path.resolve(__dirname, 'wwwroot'),
        publicPath,
        filename: '[name].[contenthash].js',
    },
    optimization: {
        moduleIds: 'deterministic',
        splitChunks: {
              chunks: 'all',
        },
        runtimeChunk: false,
    },

The worker import code in the transpiled code I see:

return new Worker(
    new URL(/* worker import */ __webpack_require__.p +  
    __webpack_require__.u(
        "src_functions_parallelism_caching_passport-worker_ts-_36b50"), __webpack_require__.b), {
            ...

Not sure if it's OK or relevant to the problem, pasting here just in case.

What is the expected behavior?

The expected behaviour is that worker import is able to resolve the correct script name (with the contenthash appended).

Other relevant information:
webpack version: 5.44.0
Node.js version: 14 LTS
Operating System: Mac OS
Additional tools:

[wh1t3cAt1k]

Added additional context into the issue, please take a look.

[alexander-akait]

Please use publicPath: auto

[alexander-akait]

You have invalid URL

[wh1t3cAt1k]

@alexander-akait are you sure it's a question of public path?

To reiterate, the worker import was working properly before I added [contenthash] into output.filename.

(In my case publicPath is a variable I define in advance in the configuration, its value seemed irrelevant since it was working without the [contenthash], so I didn't paste it)

[alexander-akait]

Please provide reproducible test repo, otherwise we can't help here, maybe other plugin break contenthash

[wh1t3cAt1k]

Some more context before I jump into test repo:

I tried replacing filename: '[name].[contenthash].js', with filename: '[name].[chunkhash].js'.

The runtime still tries to import a non-existent script, but instead of undefined, it references a chunkhash that is not present in the filename.

I.e. the browser tries to load chunk-id.5deff33769142387d785.js , but in the filesystem, the only file present is chunk-id.d8777908f84bf2d38dc5.js – Different hash for some reason.

The "non-existent" hash is also referenced in chunk filename in the compiled code (hence the attempt to load the script from that path).

@alexander-akait

Is there a way that [chunkhash] may change throughout the compilation, so that the file is created with one hash, but compiled code expects a different one?

P.S. the above also explains why I didn't have any problems when using just [name].js for output filename...

[wh1t3cAt1k]

During build time, I see a warning that might be relevant:

[webpack] (node:3343) [DEP_WEBPACK_MODULE_UPDATE_HASH] DeprecationWarning: Module.updateHash: Use new ChunkGraph API

[alexander-akait]

It means you have plugin which break hash/contenthash/etc

[alexander-akait]

I don't know why it is hard to use the issue template and provide example how we can reproduce, this will not only make your life easier, but also reduce the time spent trying to guess, and will also save your nerves

[wh1t3cAt1k]

I used the issue template as is; re reproducible repo, agree it's not hard, just time consuming to strip down the NDA-protected codebase down to a reproducible example.

Thus, I am trying to figure out the potential root cause as is first, failing that I'll work on bringing the example to the table.

For the record, I managed to get rid of the above warning by updating all my plugins, the issue was not gone.

I am beginning to suspect this:

[webpack] WARNING in [entry]
[webpack] Circular dependency between chunks with runtime (src_functions_parallelism_caching_passport-worker_ts-_36b50, src_functions_parallelism_caching_passport-worker_ts-_36b51, src_functions_parallelism_calculation_function-worker_ts, taskpane)

This error is caused by the fact that in a certain file, depending on the browser, I instantiate either a SharedWorker, or a Worker, but within both I import the same script path.

Apparently Webpack 5 cannot merge them into one chunk so I end up with two chunk bundles with identical content:

By the looks of things, maybe the chunkhash part in the filename gets overridden due to the above warning.

My working day is over, if I don't sort this problem out I am going to work on a repro.

[alexander-akait]

unfortunately there can be many problems here, I cannot help without repo 😞

[AprilArcus]

I'm having the same issue as @wh1t3cAt1k, in conjunction with waysact/webpack-subresource-integrity.

See also: waysact/webpack-subresource-integrity#165
Minimal reproduction: https://github.com/AprilArcus/webpack-sri-workers-contenthash-repro

[roninjin10]

I was able to make @AprilArcus even more minimal by stripping down the webpack-subresource-integrity plugin to the minimal it needs to cause this behavior. I added console.logging to node_modules/webpack/lib/runtime/GetChunkFilenameRuntimeModule.js and noticed there that by simply tapping into mainTemplate.hooks.localVars.tap and doing nothing else it triggered this behavior. I'm not 100% but I'd guess from looking at the code this happens in every async chunk.

link: AprilArcus/webpack-sri-workers-contenthash-repro#1

[alexander-akait]

Reproducible example https://github.com/AprilArcus/webpack-sri-workers-contenthash-repro

[roninjin10]

Here is my investigation into this issue that lead to helping produce the minimal example:

If using contenthash with a WebWorker and any plugin is calling Maintemplate.prototype.hook.localVars such as the webpack-subresource-integrity plugin, the runtime starts requesting for undefined when it tries to load the web worker chunk both observed in the console and from adding logging in webpacks source .

Since this is happening as a sideeffect of calling .tap, I think the issue lies downstream of

webpack/lib/RuntimePlugin.js

Line 365 in c181294

mainTemplate.hooks.localVars.isUsed() ||

but I'm not sure.

[kon72]

Here is another reproduction: https://github.com/kinsei0916/webpack-worker-contenthash-repro
I'm not using any additional plugins other than html-webpack-plugin. This issue occurs when I bump webpack-dev-server from 3.11.2 to 4.0.0.

[alexander-akait]

Marked as critical, we will fix it in near future

[alexander-akait]

Fix #14112

[alexander-akait]

Please try https://github.com/webpack/webpack/releases/tag/v5.51.2

[remcohaszing]

It’s working now (remcohaszing/monaco-yaml#100) 🎉

[alexander-akait]

Let's close, feel free to feedback if you faced with bugs again

[wh1t3cAt1k]

I confirm that the issue has disappeared for me as well after the upgrade. Thank you for the fix.
I am also grateful to the guys above who were able to provide the minimal repro as I never got around to doing it.