Replies: 6 comments 30 replies
-
|
In theory we can implement |
Beta Was this translation helpful? Give feedback.
-
|
Something like this? and then this?
Will this break in node/jest when the query string is reached? |
Beta Was this translation helpful? Give feedback.
-
|
is there a way to directly test in |
Beta Was this translation helpful? Give feedback.
-
|
@AprilArcus , related: #14198 |
Beta Was this translation helpful? Give feedback.
-
|
Did anyone manage to find a workaround to build and load inline workers? We stumbled upon the same issue. |
Beta Was this translation helpful? Give feedback.
-
cfg.module.rules.unshift({
test: /\.wasm/,
type: 'asset/inline'
})1.a) If this is a [static] third-party worker (like QR code reader or audio processor), then add it to public directory and reference it via full path. Code would look like 1.b) If you are actively working on the worker code, you need to use Note: you may or may not need the eslint line (depending on your webpack config) and you may or may not need Then, where you would need a Note: as a side-effect, there may be a randomly named file appearing in the root of your "dist" folder with contents of the |
Beta Was this translation helpful? Give feedback.
-
|
I am also currently facing challenges in regards to WebPack and WebWorkers (+AudioWorklets). While I could figure out most of my aspects, exactly the point of having inline workers is still open. So I'm joining here the discussion related to the support of inline workers. The
Case 1: I would vote for a new syntax which triggers the same worker generation logic like today, but not being dependent on the |
Beta Was this translation helpful? Give feedback.
-
|
@alexander-akait As per my proposal I started with a change which would introduce a new module variable. I have it over at my fork https://github.com/Danielku15/webpack/tree/feature/inline-workers (diff here). It basically consists of following changes:
The trickiest part was to get it running in the test environment because the whole worker part is customized in the WebPack worker environment to run in a Node environment. I had to fiddle a bit to get the tests working and I couldn't make a full test because I ran into strange syntax errors being reported if I used imports in the inline workers. I didn't dare yet to open a PR because we don't have confirmation yet if the additional module variable would be your preferred solution to this problem. But it gives an idea. The tests give a good indication about how it would be used: If you are fine with this path, I could open a PR for a more detailed discussion on the code changes and what further tests should be added. If this change finds its way into WebPack, I would try to also build on top of this a worklet support (#11543). For this I would then need to adapt the built-in |
Beta Was this translation helpful? Give feedback.
-
|
@Danielku15 I'm interested whether you find any solution since your last comment. |
Beta Was this translation helpful? Give feedback.
-
|
@veeramarni Yes, for one use case I need, I was able to build a solution that works form me. But it only works when consuming the library I built through NPM. In my library code I spawn my worker through: const worker = new Worker(/* webpackChunkName: "mylib.worker" */ new URL('@mylib/mylib', import.meta.url)The You can see it live here: The code which spawns the worker: https://github.com/CoderLine/alphaTab/blob/ca4673373d19759c64f76b98b90cfe2955b86a25/src/Environment.ts#L224 I hope it helps you to build something that might work for you too. The goal is to really use the |
Beta Was this translation helpful? Give feedback.
-
|
@Danielku15 I got stuck here. When i import as string It will only import the blob as
|
Beta Was this translation helpful? Give feedback.
-
|
@veeramarni I think you have misunderstood a bit my message and my code. I have no running version where with some magic strings or combinations you could create an inline-string with a blob. Instead of using a blob worker, I use now the built-in capabilities of WebWorkers in WebPack. The current WebWorker support requires you to launch your worker exactly with a syntax like My pain point in WebPack was that I develop a library which spawns itself as worker and within the library I didn't know what to write for And this usecase I could solve by 1. detecting whether my library has been bundled with webpack and 2. by assuming that something like '@my/lib/src/worker.js' will resolve within WebPack correctly to my file. Combining this together a
Here a smaller reference example: // node_modules/@my/lib/deep-thought.js
export function launchDeepThought(question) {
const worker = new Worker(new URL('@my/lib/deep-thought.js', import.meta.url));
worker.postMessage({
question: question
});
worker.onmessage = ({ data: { answer } }) => {
console.log(answer);
};
}
if (typeof WorkerGlobalScope !== 'undefined' && self instanceof WorkerGlobalScope) {
self.onmessage = ({ data: { question } }) => {
self.postMessage({
answer: 42,
});
};
}
// app.js
import { launchDeepThought } from '@my/lib/deep-thought.js';
launchDeepThought('The Answer to the Ultimate Question of Life, The Universe, and Everything.');I am the author of a simple library "deep-thought" which can launch itself in a worker. It is consumed through NPM in another app. There the worker is launched through a I didn't know what to write to launch my worker because I needed a way to resolve the final URL of the file where my library will be contained (e.g. vendor.js or chunk-deep-thought.js). But with this mechanism of using the library name and the exact syntax that WebPack supports it works. I have no solution or approach to let WebPack convert Hopefully this makes it a bit clearer to you. |
Beta Was this translation helpful? Give feedback.
-
|
ok thanks for the explanation. I ended up creating webpack config for the worker file and used webpack config of the package And for worker, i do something like this |
Beta Was this translation helpful? Give feedback.
-
|
I need this.I think it is very import feature. |
Beta Was this translation helpful? Give feedback.
-
|
If you are developing a library I suggest to use esbuild with https://github.com/mitschabaude/esbuild-plugin-inline-worker It's simple and works flawlessly. |
Beta Was this translation helpful? Give feedback.
-
|
I could bypassed the cross-origin problem with this trick instead of inlining the worker code. This is just a workaround, but I hope it helps someone for now. And huge thanks to the original author, @piotr-oles. I would just copy and paste the code for reference: export class CorsWorker {
private readonly worker: Worker;
constructor(url: string | URL) {
const objectURL = URL.createObjectURL(
new Blob([`importScripts(${JSON.stringify(url.toString())});`], {
type: 'application/javascript'
})
);
this.worker = new Worker(objectURL);
URL.revokeObjectURL(objectURL);
}
getWorker() {
return this.worker;
}
}import { CorsWorker as Worker } from './cors-worker';
// aliasing CorsWorker to Worker makes it statically analyzable
const corsWorker = new Worker(new URL('../worker', import.meta.url));
// tada!
const worker = corsWorker.getWorker();The idea is using a wrapper class FYI: This is the code in my actual project. The caller file where the wrapper class is imported as |
Beta Was this translation helpful? Give feedback.
-
|
In latest webpack, that's a https://webpack.js.org/configuration/output/#outputworkerpublicpath |
Beta Was this translation helpful? Give feedback.
-
I need to host all assets in CDN, but Web Worker requires the same domain policy.
The below code works correctly if I don't use CDN.
Here are the docs https://webpack.js.org/guides/web-workers/, but they don't mention how to make inline workers.
worker-loader for webpack4 https://github.com/webpack-contrib/worker-loader#cross-origin-policy
In the old approach, there is a workaround for it, but I can't find any solutions for wepback5.
I know, it's possible to use a proxy from the same domain, but I need to use CDN because of the performance.
Beta Was this translation helpful? Give feedback.
All reactions