Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Error when using dynamic imports #43

Closed
FTWinston opened this issue Sep 23, 2019 · 6 comments · May be fixed by #60
Closed

Error when using dynamic imports #43

FTWinston opened this issue Sep 23, 2019 · 6 comments · May be fixed by #60

Comments

@FTWinston
Copy link

FTWinston commented Sep 23, 2019 •
edited

If I include the following in my worker code (assuming dummyModule.js just contains export default 1)

const unusedImport = () => import('./dummyModule')

then I get this error:

./src/myWorker.ts (./node_modules/worker-plugin/dist/loader.js?{"name":"0"}!./src/myWorker.ts)
ChunkRenderError: Conflict: Multiple chunks emit assets to the same filename static/js/0.chunk.worker.js (chunks 0 and 0)

Is this something we can work around with worker-plugin's options?
@FTWinston
Copy link
Author

FTWinston commented Sep 24, 2019 •
edited

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.

@FTWinston FTWinston mentioned this issue Sep 24, 2019
Closed
@qidaneix
Copy link

qidaneix commented Nov 2, 2019

hi bro, will your eslint throw error when you use ts with worker-plugin? mine did, and donot know why

@dragly
Copy link

dragly commented Nov 5, 2019

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.

@art-in
Copy link

art-in commented Jan 16, 2020

This shouldn't be closed since workaround is not a real fix.

@gluck
Copy link
Contributor

gluck commented Mar 9, 2020

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 ™️ way to go.

@developit
Copy link
Collaborator

@gluck that actually seems like a pretty good solution. Definitely open to a PR, we can see if it still passes the tests.

gluck added a commit to gluck/worker-plugin that referenced this issue Mar 9, 2020
@gluck
Change worker chunk name from <ID> to w<ID>
56f2ca5 
Fixes GoogleChromeLabs#43, as it avoids conflicts with other number-based webpack
chunks.
Note that the conflict may not be on the filename (since this plugin
adds '.worker' to it) but on the internal key used by webpack in
referencing modules.
@gluck gluck mentioned this issue Mar 10, 2020
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Change worker chunk name from <ID> to <ID>.worker gluck/worker-plugin
6 participants
@developit @dragly @gluck @art-in @FTWinston @qidaneix