Resolve error when using nested Workers + self-referential Worker #8727
Comments
|
cc @mischnic @devongovett as the two people who looked at the original mentioned issue |
|
Sounds a bit similar to #5504 but that one was resolved long ago. |
|
I cloned that branch, cd'ed into |
|
That's odd. You can see the same error I had locally on the CI too: https://github.com/GoogleChromeLabs/wasm-bindgen-rayon/actions/runs/3807848746/jobs/6477924018#step:3:192 (and I only now noticed that error is not correctly propagated to CI status, I'll fix that separately but that's beside the point anyway) |
|
Ah, I think it's because the last command ran |
|
Pushed an update to the repro branch, you should now be able to do |
|
Friendly ping - have you had a chance to take another look? |
|
Just ran into this issue again. Generally it will affect ~all Emscripten projects using pthreads and being built by Parcel, as well as wasm-bindgen-rayon projects like in example above. Any chance someone would look into this? It's been a while. |
Even in ESM mode, we use dynamic import to load main code from the Web Worker, so, technically, our Workers dont *have* to be ESM as well - they're compatible with regular script mode too.
Unfortunately, unlike browsers, some bundlers care about the distinction and don't bundle Workers correctly when `new Worker(...)` is used without `{type: 'module'}`. Some recent examples where I've seen this:
- issue with parcel bundler: parcel-bundler/parcel#8727 (comment)
- issue with esbuild bundler used by popular vite toolchain: GoogleChromeLabs/web-gphoto2#12
In both cases adding `{type: 'module'}` fixes the build.
One difference this change will make is that `{type: 'module'}` forces Worker to be loaded as a module which always runs in strict JS mode.
Our main code should already be compatible with `use strict`, or it wouldn't work as ESM at all, and our `src/worker.js` code has `use strict` at the top, so it's compatible too, so I don't expect any issues, but it's something worth keeping in mind if we get breakage reports.
Also note that older browsers without Module Workers support will ignore `{type: 'module'}` and run Workers in script mode, so as long as we don't use static imports or `import.meta.url` in `src/worker.js`, this is a backward-compatible change.
Even in ESM mode, we use dynamic import to load main code from the Web Worker, so, technically, our Workers dont *have* to be ESM as well - they're compatible with regular script mode too.
Unfortunately, unlike browsers, some bundlers care about the distinction and don't bundle Workers correctly when `new Worker(...)` is used without `{type: 'module'}`. Some recent examples where I've seen this:
- issue with parcel bundler: parcel-bundler/parcel#8727 (comment)
- issue with esbuild bundler used by popular vite toolchain: GoogleChromeLabs/web-gphoto2#12
In both cases adding `{type: 'module'}` fixes the build.
One difference this change will make is that `{type: 'module'}` forces Worker to be loaded as a module which always runs in strict JS mode.
Our main code should already be compatible with `use strict`, or it wouldn't work as ESM at all, and our `src/worker.js` code has `use strict` at the top, so it's compatible too, so I don't expect any issues, but it's something worth keeping in mind if we get breakage reports.
Also note that older browsers without Module Workers support will ignore `{type: 'module'}` and run Workers in script mode, so as long as we don't use static imports or `import.meta.url` in `src/worker.js`, this is a backward-compatible change.
Now that wasm-bindgen has `wasm_bindgen::link_to!`, we can use it to ensure that Worker is emitted alongside the snippet file instead of having to use the snippet file itself as a Worker source. In turn, this allows to use static import of the main module in the Worker, which avoids unnecessary extra code splitting we used to have. Aside from slightly better chunking, this also happens to work around the Parcel issue parcel-bundler/parcel#8727.
|
Pretty sure this is still a issue, although there hasn't been a response after initial submission. |
mischnic
added
the
Stale Ignore
🐛 bug report
I'm getting Parcel runtime error when it tries to resolve some chunk in a built Web Worker. I suspect this is a continuation of my issue from #5920, except now I had to add nested Workers (one Worker spawning another) to the mix.
🎛 Configuration (.babelrc, package.json, cli command)
$ parcel build index.html --dist-dir pkg/parcel --public-url .🤔 Expected Behavior
No error should occur.
😯 Current Behavior
When building wasm-bindgen-rayon tests, I'm getting a resolution error with Parcel at runtime after a successful build. Other bundlers as well as a no-bundler modes work fine:
FWIW this is the stacktrace resolved via sourcemap if I try to open it directly in browser instead of using Puppeteer:
💁 Possible Solution
No idea what's going on there.
🔦 Context
This library is used to support Rust multithreading library Rayon on the Web via Wasm + Web Workers.
💻 Code Sample
To make it easier to reproduce without dealing with nightly Rust & wasm-pack toolchains, I just committed all the prebuilt assets to a separate branch: https://github.com/GoogleChromeLabs/wasm-bindgen-rayon/tree/with-prebuilt-assets
You can find Parcel assets here and their sources here.
🌍 Your Environment
The text was updated successfully, but these errors were encountered: