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

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

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

- pass ThreadsWorkerOptions options to the worker constructor

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

Would be really nice to merge this

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.