feat: support choosing custom worker backend

[aminya]

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]

Thanks for the PR, @aminya! Can you check why the rollup build is failing?

[aminya]

@andywer It works for me locally. It says getWorkerImplementation is not exported while it is! This is weird.

[aminya]

@andywer This is ready to go.

[andywer]

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.

[aminya]

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?

[andywer]

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.

[aminya]

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.

[andywer]

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"?

[aminya]

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?

[aminya]

@andywer I rebased this, and in the next commit, I removed createWorker export from index:

[andywer]

Thanks so much, @aminya!

I will go through this PR once more in-depth before merging it, but it looks really good.

[aminya]

Any plan to merge this?

[andywer]

@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.

[aminya]

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!

[flux627]

Would be really nice to merge this

[DonovanDMC]

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.