Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Split chunks are not being loaded in the webworker target

See original GitHub issue

Bug report

What is the current behavior?

The chunks are not imported (no occurrences of importScripts in entry chunks) so an error is thrown:

Uncaught TypeError: Cannot read property 'call' of undefined        worker-a.js:20
__webpack_require__ @ worker-a.js:20
(anonymous) @ worker-a.js:93
__webpack_require__ @ worker-a.js:20
(anonymous) @ worker-a.js:84
(anonymous) @ worker-a.js:87

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

Repo: https://github.com/Alexendoo/bugs/tree/master/02-webpack-worker-chunks Hosted: https://alexendoo.github.io/bugs/02-webpack-worker-chunks/ (nothing to display, just the errors in console)

The above setup has two entries, worker-a and worker-b that have a common shared dependency on shared.js, it sets minSize: 0 and chunks: "initial" in splitChunks to force a separate chunk to be created

The output of running webpack can be seen in dist/, neither worker-a.js nor worker-b.js import worker-a~worker-b.js

The bug also occurs when adding a named chunk to cacheGroups

What is the expected behavior?

Both worker-a.js and worker-b.js should import the chunk in worker-a~worker-b.js, through importScripts or some other mechanism

Other relevant information: webpack version: 4.16.5 Node.js version: 10.7.0 Operating System: Windows 10 Additional tools: none

Issue Analytics

State:
Created 5 years ago
Reactions:4
Comments:15 (6 by maintainers)

Top GitHub Comments

1reaction

qraynaudcommented, Sep 3, 2019

On my side, I’m using import _ from 'lodash' in my worker. It does work but instead of loading the lodash chunk (using importScript) that was generated by the main app, it copies the full lodash codebase inside my worker file. That is a shame since it’s making a 13kb worker into a 1.3 Mb one!

I hope initial chunks will be loaded properly soon 😉.

If I can help, I would be glad to, but I have to admit I have no idea as to how to fix this. I looked a little in the codebase but it is hard to get to know it right now.

0reactions

sokracommented, Oct 29, 2020

This is still a real issue even if it’s inactive. I don’t understand this bot. I never knew waiting issues out was a way to fix them ! 😛

We can’t fix everything. Piling up issues neither fixes them.

But anyway this is fixed in webpack 5

Top Results From Across the Web

Webpack: Common chunks for code shared between ...

Webpack loads chunks with document.createElement('script') and document.head.appendChild() sequence, which is not available in worker ...

Web Workers | webpack - JS.ORG

As of webpack 5, you can use Web Workers without worker-loader . Syntax. new Worker(new URL('./worker.js', import.meta.url)); // or customize the chunk name ......

webpack-cli - npm

webpack CLI provides a flexible set of commands for developers to increase speed when setting up a custom webpack project. As of webpack...

Build Targets - SurviveJS

You cannot use webpack's hashing features when the webworker target is used. ... It uses standard Node require to load chunks unless the...

Using Webworkers with Webpack - Sebastien Dumetz

Fortunately, webpack provides a webworker target. ... starting a web worker is man,aging updates : You want cache to be invalidated EVERY ...