Worklet support

[hughrawlinson]

Hi,

I'm writing to ask if you would be open to a PR adding support for other types of worker-like constructs such as Worklets. There are several other constructs that require an almost identical setup, but use a different constructor, such as:

• navigator.serviceWorker.register(moduleId)
• CSS.paintWorklet.addModule(moduleId)
• new AudioContext().audioWorklet.addModule(moduleId)

This could be accomplished in a couple of ways.

If the answer is a clear "no, this project is for Workers only", feel free to skip everything below, I understand completely.

Adding additional factory types

We could implement additional factories like the existing createInlineWorkerFactory method for each of the above Worker/Worklet types. Then, modify the options type to accept a parameter choosing Worker/Worklet type. At the same time, that would require this project to be aware of all the relevant W3C specs, and keep up to date with them.

Custom factory

If the user could specify a custom factory, we don't need to update this project whenever a new Worker-ish API is released. They could also specify parameters to Worker-ish constructor if they needed to.

Provide a way to import the encoded bundle as base64 directly

(I'm new to rollup so there might be an obvious way to do this already that I'm unaware of. If that's the case, sorry in advance!)

If web-worker-loader were configured to return the base64 encoded bundle, or blob, instead of doing the following:

import MyWorker from "web-worker:./my-worker.js";
// Right now this code would call the Worker constructor in one of the Factories
// which is not what we want in the case of the other Worker-like constructs
const w = new MyWorker();

you could have the user actually instantiate the Worker-ish object

import MyAudioWorklet from "audio-worklet:./my-audio-worklet.js";
myAudioContext.audioWorklet.addModule(MyAudioWorklet);

---

Whether or not you're interested in getting support for these in this project, I would value your feedback on the API options - but no pressure!! Thanks for taking the time to read this.

[hughrawlinson]

I hacked around a little on this and have a tiny proof of concept and demo.

[darionco]

yup this is a good idea, I think it would be nice if the plugin would have different patterns for the different types of workers, that way it could also have a base64 pattern to import the worker as a string or a blob pattern to import it as a blob or blob URL. As your example suggested. The options could be:

// web worker
import Worker from './code.web.worker.js'; // extension
import Worker from 'web-worker:./code.js'; // prefix

// audio worklet
import Worklet from './code.audio.worklet.js'; // extension
import Worklet from 'audio-worklet:./code.js'; // prefix

// etc...

(I am more inclined to use extensions because that way file names are explicit but that is personal preference)

So in the end the plugin would have a pattern configuration option for each worker type:

pattern?: RegEx,

would become:

webWorkerPattern?: RegEx,
audioWorkletPattern?: RegEx,
// etc...

this could be version 2.0 of the plugin too!

[hughrawlinson]

Thanks! I'll look into this and see how far I can get! 😄