ESM Modules Support / importScripts Errors

[thecynicalpaul]

Hi there, thank you for the wonderful work upkeeping this as always.

Not sure if this is the right place, but wanted to get some insight on this. Our team is currently in the process of transitioning our main project to webpack 5, and we are unable to get worklets working with it. Essentially, webpack is splitting imports that we have inside our WorkletProcessor code into chunks and tries to inject them back using importScripts directive at run-time. From what I understand, importing doesn't work in processors whatsoever (please correct me if I am wrong), and so we are stuck there.

Please take a look at the issues being outlined here:
webpack/webpack#11543
vercel/next.js#24907
vercel/next.js#29472

Would love to hear your thoughts on this, and see if anything can be done from your library's side, or if there is anything that we could be doing right, as our knowledge of WebAudio is not as advanced.

[chrisguttandin]

Hi Pavel,

thanks for your nice words.

I'm pretty sure that importScripts is not part of the AudioWorkletGlobalScope. But the newer import statement is officially available. Sadly it doesn't work in Firefox and Safari.

standardized-audio-context/test/expectation/firefox/current/audio-context-constructor.js

Line 12 in 8a3c874

describe('with a module which contains an import statement', () => {

standardized-audio-context/test/expectation/firefox/current/audio-context-constructor.js

Line 12 in 8a3c874

describe('with a module which contains an import statement', () => {

I think it would be theoretically possible to implement this somehow as part of standardized-audio-context but it would be a lot of work and it would significantly increase the bundle size. I'm not sure if it would be desirable anyway. I think for performance reasons it's better to not do any module resolution on the audio thread and instead load a bundle without any external imports.

An alternative would be to use the global scope. By definition there is only one AudioWorkletGlobalScope per AudioContext which is why the following should work.

// a.js
const a = 1;

// b.js
const b = a + 1;

await audioContext.audioWorklet.addModule('./a.js');
await audioContext.audioWorklet.addModule('./b.js');

Sadly this is not supported in Chrome (and Edge and Opera).

standardized-audio-context/test/expectation/chrome/any/audio-worklet-node.js

Line 23 in 7eadfab

describe('with a module depending on another module', () => {

standardized-audio-context/test/expectation/edge/any/audio-worklet-node.js

Line 23 in 7eadfab

describe('with a module depending on another module', () => {

standardized-audio-context/test/expectation/opera/audio-worklet-node.js

Line 23 in 7eadfab

describe('with a module depending on another module', () => {

From reading the issues that you referenced (and from my experience) I can see that bundling an AudioWorklet with webpack is still super complicated. However I think generating a full bundle without any external dependencies is the only way to make it work across all browsers for now.

I hope this helps.

[thecynicalpaul]

Thanks for the detailed analysis, Chris! Very much appreciated, and we'll see what we can do with this. Will post any updates if we come across anything breaking, as I am sure others could benefit from this as well.

[chrisguttandin]

Yes, please. I'm sure this is a problem many people struggle with.

Another option that just came to my mind would be to move your AudioWorklet code into an external package. I did this with the limiter-audio-worklet package. It's almost empty and only contains a precompiled and inlined version of the limiter-audio-worklet-processor. It's still not ideal since you increase the main bundle and loose the option to transpile the code with the rest of your application. But it's very convenient and works as any other package in the end.