Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

worker_threads compatibility? #10

Open
guybedford opened this issue Oct 9, 2018 · 12 comments
Open

worker_threads compatibility? #10

guybedford opened this issue Oct 9, 2018 · 12 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@guybedford
Copy link

Understood if this is off-topic, and feel free to close, but I was just wondering if you'd considered compatibility with Node.js worker_threads here at all?

It seems like the sort of thing that would be generally useful for Node.js optimization as well, in having some kind of --node output, since you're already in the game of worker builds.

Although perhaps, a translation layer from web-style workers to Node.js-style worker_threads would be the better route as its own project.

Otherwise do you know anyone working on this problem / who considers this important?

@developit
Copy link
Collaborator

This seems worthwhile! It would also be interesting to see if it could be handled automatically by output.target=node.

I've been following Node's workers stuff and would be interested in collaborating if you're looking at a shim layer.

@guybedford
Copy link
Author

My primary concern here right now is Node.js going stable with worker_threads before these workflows as discussed above have been explored at all, by anyone.

If there are issues / frictions I think it would be important to get that into the Node.js feedback process before worker_threads are unflagged as experimental and the API is cemented.

Perhaps all will be fine though, in which case, great.

This project seems the closest to the edge of future worker build workflows that I can find right now - thanks for being open to have the discussion here.

@developit
Copy link
Collaborator

Sorry for falling off this thread - I agree. I am going to try to find some time to set up tests against worker_threads so I can see what the delta is between what we output today and what needs to be supported.

I'm curious if you envision worker-plugin as being the right place to "patch" worker_threads to include things like addEventListener?

@developit developit added enhancement New feature or request help wanted Extra attention is needed labels Dec 3, 2018
@guybedford
Copy link
Author

I'm curious if you envision worker-plugin as being the right place to "patch" worker_threads to include things like addEventListener?

Definitely, would be good to DM further about this if you have a moment.

@andywer
Copy link

andywer commented Apr 26, 2019

Node 12 is out, shipping worker_threads without the feature flag. Might be the right time to get back to this? 😉

@fridgerator
Copy link

Also interested in this feature!

@developit
Copy link
Collaborator

@guybedford and I ended up coming up with a longer-term plan for this, which should be easy to support in Worker Plugin.

In the interim, I believe the following should work today with Worker Plugin:

const { Worker } = require("worker_threads");

const worker = new Worker("./my-worker.js", { type: "module" });

@guybedford
Copy link
Author

@developit that seems like a good approach. It's worth noting though that there are a lot of differences between worker threads and native workers. See eg nodejs/node#30682 (comment).

The simple difference from your example is "./my-worker.js" doesn't work as a worker reference in Node.js as it is a process.cwd-relative path not a module-relative URL.

The list is basically:

  1. Use new URL('./worker.js', import.meta.url) as the input to the Worker call (as soon as worker_threads: allow URL in Worker constructor nodejs/node#31664 lands)
  2. worker.addEventListener is worker.on in Node.js
  3. self.addEventListener in a worker is require('worker_threads').parentPort.on in Node.js
  4. In Node.js worker event data e.data must be accessed without the .data part.

I think this is simply too much compat friction for your approach mentioned above to work for any user that doesn't have half a day to mess around with this stuff....

@developit
Copy link
Collaborator

Good point, agreed! I think the shim module is probably a better way forward. Need to release it..

@mihanizm56
Copy link

any updates?

@DarrenCook
Copy link

We're using worker-plugin (and I now need it to work from node too). I was hoping to find a comparison with https://github.com/developit/web-worker

But having read this thread I'm wondering if web-worker is basically the solution being described here? Would love to hear from someone if there are downsides to switching from worker-plugin to web-worker.

@developit
Copy link
Collaborator

developit commented Sep 12, 2022

@DarrenCook I believe the solution is to use both. worker-plugin generates the code for the worker, and web-worker provides a Worker global that can be used by that code.

You likely need to do something like this:

import WebWorker from 'web-worker';

globalThis.Worker = WebWorker;

new Worker(
  new URL('./worker.js', import.meta.url),
  { type: 'module' }
);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

6 participants