Comments (22)
It is very easy to implement, anyway why you need inline?
I think it is just nicer to ship one single file, but that might be an outdated point of view :)
EDIT: obviously shipping libs as bundles is not outdated, but i guess seeing a worker like another chunk that gets loaded on demand might be a valid approach sometimes better than having to ship a single large file ... nevertheless many projects using worker-loader use inline, and thus the expectation on the distro end is that there is one single JS file. changing that might cause breakage potentially if that is the assumptions made on some consuming sides...
from worker-loader.
code splitting will not work, also caching can be broken
from worker-loader.
Should be needless to say this requires obviously to shim the global namespace like so first of all:
const {Worker: NodeJSWorker} = require('worker_threads');
const {resolve: resolvePath} = require('path');
global.Worker = function NodeJSWorkerThreadsPathResolveWrap(path, options) {
// this __dirname will travel into the bundle and only resolved at
// runtime there, so it will be the path to the dist bin
// and we can assume to find the worker there.
// generally, this has to be an absolute path with NodeJS worker-threads,
// so this is why we use resolve here and not join.
return new NodeJSWorker(resolvePath(__dirname, path), options);
}
This is TypeScript plain JS, and the symbol name NodeJSWorkerThreadsPathResolveWrap
is completely arbitrary choice.
EDIT:
and inside webpack conf:
node: {
__dirname: false, // this is important so that __dirname
// gets into bundle as vanilla and only resolved at runtime
},
Very simple setup, and harmless if you dont need __dirname resolving by webpack (which is ugly as hell to do anyway I think).
Otherwise, everything works just fine like for webworker, since it is API compatible.
from worker-loader.
Just note - webpack@5
support workers (web workers and Node.js worker threads) out of box, you don't need this loader, it was deprecated someday (need improve docs)
/cc @chenxsan Do we have examples/guide for web workers and etc stuff?
from worker-loader.
Example from source https://github.com/webpack/webpack/tree/master/examples/worker
from worker-loader.
No, PR welcome to docs
from worker-loader.
@yvele I am using this with NodeJS target, it is absolutely no problem.
It works just the same as for web platform workers. The APIs are compatible, even if NodeJS provides other tools on top,but that shouldnt be concern of this loader here.
What exactly is the problem you face? I can provide my config as example in case needed.
from worker-loader.
Just note - webpack@5 support workers (web workers and Node.js worker threads) out of box
Really? Then what is this project still about? It should indeed be shown first thing in readme I guess :)
from worker-loader.
Really?
Yep
Then what is this project still about?
For migration purpose, also some features like inline
(Blob
) is not implemented
It should indeed be shown first thing in readme I guess
I want to do it after improving docs on site with link
from worker-loader.
For migration purpose, also some features like inline (Blob) is not implemented
if the webpack v5 built-in thing doesnt support inline, then it is not that useful :) and this plugin here is still not replaceable by anything else indeed for me.
from worker-loader.
Just note -
webpack@5
support workers (web workers and Node.js worker threads) out of box, you don't need this loader, it was deprecated someday (need improve docs)/cc @chenxsan Do we have examples/guide for web workers and etc stuff?
I'm afraid no.
from worker-loader.
@tchakabam It is very easy to implement, anyway why you need inline?
@chenxsan Do you need help?
from worker-loader.
@alexander-akait I've created an issue to track it.
from worker-loader.
I have added node's worker_threads support in this PR #313.
I was able to build and run locally, but haven't added any test case to the PR.
Comments and collaboration are welcome.
from worker-loader.
@tranvansang What is webpack version? webpack v5 supported worker (browser/node) out of box
from worker-loader.
I am using the quite new one ^5.28.0
.
I gave it a try but couldn't succeed with webpack 5 natively.
So I modify the loader to first make things work in my project.
As a note that in my project, the worker using typescript and shares several module (in code) with the main thread.
And in the compiler config's public path is not the absolute path in the file system. I have to set publicPath to the same value as of the frontend's config.
If someone have ever tried and succeed, I'd like to give it another try.
I just have a question that: should I use new Worker('./my.worker')
or new Worker(new URL('./my.worker', import.meta.url))
?
I remember that I got stuck at this import.meta.url
stuff.
from worker-loader.
new Worker(new URL('./my.worker', import.meta.url))
Should work
This loader doesn't support worker_threads
and will not work in right way even with your PR
from worker-loader.
In the branch that I customized for my project.
master...tranvansang:worker_threads
It works out of the box, and I have already released it for my use.
Thanks for the answer. If webpack means to support it. I definitely will make a try.
from worker-loader.
new Worker(new URL('./my.worker', import.meta.url))
Should work
This loader doesn't support
worker_threads
and will not work in right way even with your PR
So, now I remembered how I gave up with native webpack support.
In my project, I set public path to the same value with the frontend config. For example: in production build, publicPath will be https://cdn.mywebsite.com/bundles
. This config is used extensively for assets import URL, and several URL manipulation routines which use __webpack_public_path__
.
While with the new URL
, and import.meta.url
, my assumption is that publicPath
must be the file system path. Is this correct?
Please share me anything if you know how to customize the public path of the worker threads.
from worker-loader.
Can you share your problem (simple example)? Hard to say how better to solve for you without example(s)
from worker-loader.
the migration/usage of webpack 5 was quite straightforward. I was able to use worker thread natively without the loader.
The only thing I had to do is to leave the publicPath
config empty (which made me to manually set publicPath options in file-loader
loader).
Now, I have another problem that jest doesn't work. Previously, I wrote my own transformer to fake Worker class and it ran perfectly. Now, it doesn't work with webpack-like syntax.
Because babel currently can't parse import.meta.url
, and, it doesn't spawn a child transpiler causing worker code in typescript.
I am not yet familiar with syntax like babel plugin development, so my test is currently not available for modules that use worker threads.
I will appreciate if anyone has an idea on this.
from worker-loader.
The only thing I had to do is to leave the publicPath config empty
No need to do it, please prefer to use auto
Because babel currently can't parse import.meta.url, and, it doesn't spawn a child transpiler causing worker code in typescript.
You need plugin for this
from worker-loader.
Related Issues (20)
- worker-loader does not work with "worker_threads" HOT 3
- Inline workers does not work in Edge Legacy anymore HOT 54
- worker-loader picks up webpack5 from parent folder, not webpack4 from peer HOT 12
- docs don't explain how to register ServiceWorker HOT 1
- "chunkFilename.replace is not a function" on webpack 5 HOT 5
- Inline workers not working _in_ a worker HOT 16
- Uncaught TypeError: __WEBPACK_IMPORTED_MODULE_1___default.a is not a constructor HOT 5
- Worker-loader with inline option produce cjs/loader error on build
- Cannot find module 'webpack/lib/SingleEntryPlugin' HOT 3
- Allow per-instance or per-worker-code options (such as name or constructor type) without explicit webpack rules
- build error: chunkFilename.replace is not a function at getDefaultChunkFilename HOT 5
- Document usage with Typescript / Webpack config style HOT 5
- does worker-loader work with webpack 5? HOT 4
- [feat] support load plain worker module in another worker HOT 5
- loader.option.publicPath do not work ? HOT 7
- use sharedWorker inline has the same filename HOT 2
- why 'ctx.terminate' is not wokring
- How can I import a library in worker?
- TypeError: The 'compilation' argument must be an instance of Compilation HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from worker-loader.