Threads.js Bundling
See original GitHub issueI have been thinking more about this and I realized that I don’t want to ask upstream-users of my library to bundle the workers from threads.js via webpack or parcel. It seems that there isn’t an accepted way to write a “library” using this (see https://github.com/andywer/threads.js/issues/211 and https://github.com/andywer/threads.js/issues/232#issuecomment-613159302) since you can’t get a single bundle easily. If I have this wrong, I’d love to know how to get this to work, but it seems that there isn’t an easy way to publish a library that uses threads.js without having upstream users handle the implicit code-splitting. Again, if I have this wrong, please let me know - despite the bundling, threads.js is far easier to understand/use!
I reverted to using the old web workers from an old release of GeoTIFF in my application: https://github.com/hubmapconsortium/vitessce-image-viewer/pull/160. In my testing via npm pack
I don’t seem to have any issues with the bundling and it works well. I understand the ease of parcel as well as threads.js as opposed to using webpack/webworkers but I just wanted to leave this here for anyone else who might encounter this, or if changes are desired, to help start a roadmap for them.
Issue Analytics
- State:
- Created 3 years ago
- Comments:12 (11 by maintainers)
Hey there! I don’t know if you saw it already or if it’s still an urgent topic for you, but threads.js now supports inlining worker code using BlobWorker, so you can ship master and worker code together in a single module.
Only gotcha right now: When bundling you need to run webpack twice. First bundle the worker(s) and then run webpack again for the main entrypoint code.
Thanks, much appreciated