andywer
feat: support choosing custom worker backend
This adds a function to return a worker instance based on the provided options.
- It allows us to choose between tiny and node threads.
- using dynamic import only the needed function is imported
- This is very handy for the environments that multiple workers are supported (like Electron).
- The options later can be expanded if new features are added in the future.
Fixes #285 Fixes #229
@andywer It works for me locally. It says getWorkerImplementation is not exported while it is! This is weird.
Thanks, @aminya. Need to sleep about it, though.
The issue is that this solution will only work in node.js, it won't work with webpack or parcel bundler.
Thanks, @aminya. Need to sleep about it, though.
The issue is that this solution will only work in node.js, it won't work with webpack or parcel bundler.
I have added the tests for Parcel bundler. Why do you say that it does not work?
Need to double-check, but I think the only reason why the test doesn't fail is because the worker doesn't require any bundling when tested in a node.js environment.
Background: Parcel and the webpack plugin look for new Worker() expressions. Since the syntax for the selective implementation is createWorker(), neither will recognize the code as a worker instantiation anymore and won't create a new bundle for the referenced file.
I am OK with not exporting createWorker from the index.
BTW, tsconfig-esm is configured for es2015 which is not a good compiler source e.g.: it converts awaits to yield. We should consider using esnext for tesconfig-esm.
Sorry, @aminya. Was super busy the last few days…
Yeah, maybe it's time to target a more up-to-date JS runtime like ES2017. This tsconfig.json has been around for two years – it were different times back then 😉
I am OK with not exporting createWorker from the index.
How would you use it then? Deep import á la import createWorker from "threads/createworker"?
Sorry, @aminya. Was super busy the last few days…
No worries!
Yeah, maybe it's time to target a more up-to-date JS runtime like ES2017. This tsconfig.json has been around for two years – it were different times back then 😉
Yes, I agree!
I am OK with not exporting createWorker from the index.
How would you use it then? Deep import á la
import createWorker from "threads/createworker"?
Yes, like that. I am still not sure why this is required. Is it because of the dynamic imports?
@andywer I rebased this, and in the next commit, I removed createWorker export from index:
Thanks so much, @aminya!
I will go through this PR once more in-depth before merging it, but it looks really good.
@aminya Damn, I'm so sorry. Just swamped with work right now… 🙈
Feel free to annoy me on a regular basis as much as you like until this gets shipped. I will try to find some spare time.
I added some unit tests, but the code is super fragile. The resolved worker path depends on which file I import (../src/createWorker vs ../createWorker). Also, using an absolute path doesn't work!
This is missing an export in the package, which makes it wholly unusable with esm from the get-go. Though. even after adding the export I couldn't get it to work.
