Closed FTWinston closed 5 years ago
I can work around this error by specifying a name in the worker's options:
new Worker('./myWorker.ts', { name: 'mine', type: 'module' });
I'd consider this to be a good-enough workaround.
hi bro, will your eslint throw error when you use ts with worker-plugin? mine did, and donot know why
Thanks for the workaround. Just a heads-up to anyone who tries the same:
Make sure the type comes after the name. Otherwise it will break because the type is removed from the code and a comma is left behind:
new Worker('./myWorker.ts', { type: 'module', name: 'mine' });
becomes
new Worker('./myWorker.ts', { , name: 'mine' });
This will cause bundlers to fail when using the code.
This shouldn't be closed since workaround is not a real fix.
Bit by this issue as well, I was providing a name but a non-constant one, so plugin would still go for chunkname === '0'.
I believe this is caused because '0' chunk name (provided to SingleEntryPlugin
) could eventually conflict with webpack ID-based chunk names (if you do dynamic imports or chunk splitting).
Easy fix confirmed is to use something else like 'W' + workerId
as default name argument to loader.js
.
Happy to PR this 1 line change if anyone with better webpack skills than mine can confirm it's the right :tm: way to go.
@gluck that actually seems like a pretty good solution. Definitely open to a PR, we can see if it still passes the tests.
If I include the following in my worker code (assuming dummyModule.js just contains
export default 1
)then I get this error:
Is this something we can work around with worker-plugin's options?