Our project has a similar issue. We are building a programming scratchpad that uses WebWorkers to evaluate arbitrary code. We then want to be able to include this scratchpad into other applications that want to run code locally.

The workers are correctly bundled into separate files to allow loading. However, upon spawning the workers, the application looks in the current directory for the bundle (for example /806.index.js) but the actual location is within the node_modules of your current project, i.e. /node_modules/@dodona/papyros/lib/806.index.js.

By copying the worker bundles into that location, they can be loaded, but this is of course far from ideal as you want your package to be plug-and-play.

EDIT: By using worker-loader, I managed to get it working. A big thanks to @lawrence-witt for this example repository. The idea is using worker-loader even while using webpack 5 with the following rule in your config:

{
	test: /\.worker\.ts?$/,
	loader: 'worker-loader',
	options: {
		inline: 'no-fallback'
	}
},

Import workers via

import Worker from './WorkerTimer.worker.ts';

and adding a default export to these workers

export default null as any;

This makes webpack generate a single bundle so no resolving errors take place, allowing me to publish my package as a library without any hindrances for the consumer.

@alexander-akait My goal with this issue is to provide better bundling support for workers . The current approach requires inlining workers using worker-loader, which causes the bundling output to be very large which causes latency. This gets worse if your library contains multiple workers that are not always all needed, it depends on the user’s action which worker needs to run. With the current approach, both are fetched upon loading the page instead of chunked. The issue lies in new Worker(…) that is by default outputted to some url that cannot be resolved anymore when including the library in a different package. Example in question is Papyros which is a library with workers to run the user’s code in different programming languages, that is then included in Dodona. I believe the other users in this thread have similar needs but they can elaborate where required.

thank you, I removed worker-loader from my project, looks like I need it back in again. Out of curiosity don’t you need to disable worker in

test: /\.ts?$/,
					loader: "ts-loader",
					exclude: /node_modules/,
					```

Likely not necessarry, but maybe it provides a 0.0001 ms speedup by not having to check that entire folder, just in case 😉