Conversation
|
Thanks for your PR. A few questions:
|
The reason cannot use something like This feature is mainly for more and more web applications (usually written in Typescript) that write part of the heavy modules in Rust or other programming languages, and expose the services through web worker and WASM. This change can dramatically facilitate the hybrid project development that uses Typescript and webpack, |
|
I'm not sure if it is possible to write an automated test for this. Maybe we should just test it manually in a minimal Webpack project? Maybe we can introduce an option function createWebWorker(script, workerOpts) {
return new Worker(script, workerOpts)
} Then you can use pool({
createWebWorker: (script, workerOpts) => new Worker(new URL("./hello.worker"), import.meta.url))
}) |
It would be awesome if this was supported. I'm having the same issue as the OP. The proposed const pool = Pool(() => spawn(new Worker("./workers/multiplier")), 8 /* optional size */)I think I'm going to have to go with threads instead of this well-used library for that reason alone unfortunately. |
When using workerpool in Angular or Webpack environment, usually the web worker is written in Typescript. In Webpack 5, it already can bundle the worker script automatically if using the style like mentioned in here.
In Angular, one example will be
new Worker(new URL('./worker', import.meta.url));. The "worker" url infers to the worker.ts. Webpack will automatically compile/bundle the script file for us.However, in workerpool, we can not benefit from this feature.
Thie PR aims to allow us to utilize this feature & more flexible way to use Web Worker.
The example usage is:
In Angular, we don't need to manually deal with webpack or tsc turn hello.worker.ts to hello.worker.js and put it into the assets folder. Angular cli/Webpack will do all this for us.