Workaround for Cross Origin Web Workers when using Asset Prefix

[TimoWilhelm]

Browsers will not allow you to create a worker with a URL pointing to a different domain. This creates an issue when using the Webpack 5 syntax for creating web workers new URL('/webworker/sampleworker', import.meta.url) in combination with the assetPrefix key in the config pointing at a CDN origin, since it will try to load the worker script from the CDN origin instead.

A common workaround is using a blob object URL with the script content, or using importScripts() to load the script in the worker context.

I've tried using the following snipplet to load the worker file:

const workerUrl = new URL(
    '/webworker/sampleworker',
    import.meta.url,
  ).toString();

const blob = new Blob([`importScripts('${JSON.stringify(workerUrl)}');`]);
const url = URL.createObjectURL(blob);
new Worker(url);

However, in this case the webworker/sampleworker.ts is not transpiled to JS, but rather served as a TypeScript file.

Is there any way to get a reference to the transpiled worker script without defining a custom entry point in the webpack config?

[drgx]

Any solution for this? i also facing the same problem here. Using the blob solution not working.
Is there any way to exclude assetPrefix for worker import?

Thanks!

[jantimon]

Here is a solution:
https://www.npmjs.com/package/remote-web-worker

It patches WebWorkers to use importScripts() and patches importScripts() to allow relative chunk loading:

import "remote-web-worker";

Check the code (~300bytes) here

Just make sure that the patch runs before you start using a worker.

[Deevoid]

Will this work with a worker file written in typescript. I want to re use all the functions from my app and also enjoy type safety.

[jantimon]

remote-web-worker uses the official importScripts api to load cross origin workers.

it fixes errors like:

Uncaught (in promise) DOMException: Failed to execute 'importScripts' on 'WorkerGlobalScope':
// The script at 'http://some.domain/worker.1e0e1e0e.js' failed to load.

it does not change the way how you use workers and has therefore no effects on typings

one solution to have typesave workers might be use-worker-promise. this super small library allows executing worker calculations directly from a react hook: typed example usage of a web worker

[Deevoid]

Hey! Thanks for the reply. I'm still confused. Here are my exact requirements:
I'm creating a next.js app using typescript, where I have defined lot of utility functions. While creating a web-worker file with .ts extension, I want to import those functions and also want to write the worker code using typescript.

Current progress: I'm able to create a worker file in typescript and also re-use the utility functions. Webpack 5 is able to transpile and run everything correctly.

Problem: However the problem arises when I want to run my web worker on production. On production, I serve all the static chunks created by webpack using a CDN which is enabled using assetPrefix in next.config.js file. Now since the worker file is also served from CDN, and my website is served from a different domain, the browser throws the same-origin error while creating a web-worker.

What I'm looking for is to be able to create a worker file in typescript with all the import statements intact for re-usability and be able to serve the worker file from same-origin to avoid the same-origin error. Also, other chunks are still required to be loaded from CDN only(using the assetPrefix option).
I hope I'm able to explain my problem. I'm not sure how to use remote-web-worker package to fix my problem.

[Deevoid]

I recently encountered an issue while working with web workers in Next.js, especially when dealing with different asset prefixes. I wanted to share a solution that might help others facing a similar problem.

Problem:
When creating a web worker in Next.js and your app has a specific assetPrefix set in your next.config.js file, you might encounter cross-origin policy errors if your website domain doesn't matches with the assetPrefix value. This happens because the worker chunk is served from a domain defined by your assetPrefix, causing cross-origin issues.

Solution:

1. Worker File Location:

If you have a basic worker file, give it a .js extension and place it in the public folder. This way, it will be served from the same root, avoiding cross-origin issues.

If you need to reuse functions/methods from your codebase inside your worker file, create a worker file with a .ts extension and set up the worker using Webpack 5 syntax. You can refer to Webpack's guide on Web Workers for more details.

2. Understanding assetPrefix and publicPath:

It's essential to note that the assetPrefix configuration in your next.config.js file is equivalent to the publicPath configuration in Webpack 5. You can learn more about this in Webpack's documentation on publicPath and nextjs source code.

3. Override assetPrefix at Runtime:

To address the cross-origin issue when using an assetPrefix value, you can override the assetPrefix path at runtime.

Webpack 5 exposes a global variable called webpack_public_path. You can use this variable to dynamically set and reset the asset prefix for your worker. Here's how to do it:

 // Override the asset prefix path
 // Set it to the desired value for your worker's domain
 __webpack_public_path__ = "Your-default-path" 
 // if you want your worker file to be served from the same domain use '/_next/' above.

// Spawn a new worker
const worker = new Worker(
   new URL('./path-to-worker-file', import.meta.url),
)

// Reset the asset prefix path
// Replace it with your actual assetPrefix value 
__webpack_public_path__ = "DEFAULT_ASSET_PREFIX"

`

I hope this explanation helps others facing a similar challenge! Feel free to reach out if you have any questions or need further clarification.

@TimoWilhelm If this fixes your problem, please mark it as an answer.

[Hyodori04]

I have solved cdn problem in worker same as here. But I thinkg additional config should be developed. Thank you for your answer

[Deevoid]

Glad to hear that my solution helped you. @Hyodori04 .
Could you please elaborate what do you mean by 'additional config should be developed' ?

[Hyodori04]

I mean there should be another option or config in nextjs or webpack config. Because this solution is a little bit hard to maintain code. And it can be also divided in dev and production mode. And in typescript we need to use ts-ignore. But your solution really helped me. Thank you so much

[jantimon]

@Hyodori04 did you see https://github.com/jantimon/remote-web-worker

[Hyodori04]

I didn't see deeply. But to use that we should know about build path of certain file. Isn't it?

[willwu9304]

It works for me:

Add the following code to the next.config.js：

webpack: (config, { isServer }) => {
      if (!isServer) {
        config.output.workerPublicPath = '/_next/';
      }
      return config;
},