[browser] Support for web extension constraints

[elringus]

Support for web extension constraints

The requirements for web extension are very strict: they have to be bundled as a single JS file, can't use any imports or node/browser APIs, etc. That would also refine various APIs, as, for example, new JSInterop requires loading modules for imported function at runtime from C#, which is not allowed in a VS Code web extension (#87365).

From #91558
Here is the link to the patch I'm using to strip all the offenders: https://github.com/elringus/bootsharp/blob/main/src/cs/Bootsharp.Publish/Pack/ModulePatcher/InternalPatcher.cs After the patch, bundlers are only complaining about module and process unresolved externals (tested with webpack, rollup, esbuild, vite) and the bundled runtime is working in browsers, node, deno, bun and VS Code web extensions.

Regarding module and process — would be optimal to guard them as well, though I wasn't able to find a straightforward way to do that (conditional usage still trigger bundlers). As a workaround, I'm marking them as global (eg, -g process,module in rollup), which seem to satisfy the bundlers.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

After reading https://devblogs.microsoft.com/dotnet/use-net-7-from-any-javascript-app-in-net-7/ and checking the samples I had an impression the intended use case is to run it on the main browser thread only, but it seems to be working fine under worker threads as well (#77946).

Is this something just happen to work for now, but can break in the future, or worker environment is officially supported and will be maintained under the browser-wasm runtime (ie, wasm module and associated JS wrapper won't use window or other APIs not available for workers)?

Author:	Elringus
Assignees:	-
Labels:	question, arch-wasm, untriaged
Milestone:	-

[am11]

Glad to see dotnet wasm working in constrained / sandbox environments as well! 8-)

In .NET 7, dotnet.js and dotnet.wasm were modularized and support for non-browser environments was added (e.g. node.js, v8 and for deno). Prior to .NET 7, there were only a handful of DOM / window usages in the core implementation, which were refactored in .NET 7 with guarded conditions like if (typeof window.foo === 'function') window.foo; /* else useSomethingElse() */ as part of the modularization work.

I think (hope) moving forward, we won't regress it by (re)introducing unconditional dependencies on DOM or window and therefore keep supporting sandbox environment such as Web Workers. Perhaps we can add some tests to preserve this desired state.

[elringus]

I think (hope) moving forward, we won't regress it by (re)introducing unconditional dependencies on DOM or window and therefore keep supporting sandbox environment such as Web Workers.

That's exactly what I'm concerned about, especially with all the docs and samples only mention running either on main browser thread or under node. Would be great to have an official statement somewhere (eg, https://learn.microsoft.com/en-us/aspnet/core/client-side/dotnet-interop) and associated tests covering workers (or constrained environments in general).

I'm currently using a patched .NET 6 fork to make it compatible with both node and worker environments. The prospect of migrating to stock runtime is exciting, but I need to be sure it won't suddenly break at some point.

[radical]

/cc @pavelsavara

[Kuinox]

but it seems to be working fine under worker threads as well (#77946).

Hi, I opened this issue, yes, currently I successfuly run a .NET compiler toolchain in a webworker.
Out of the box, it works on chrome, but not on firefox, because Firefox doesn't support ES modules in webworkers yet, and .NET dropped support for cjs modules.
To work around this, I use vite to convert dotnet.js into CJS:

await viteBuild(defineConfig({
    build: {
        lib: {
            entry: path.resolve(binFolder, 'dotnet.js'),
            name: 'dotnet',
            fileName: 'dotnet',
            formats: ['umd']
        },
        rollupOptions: {
            external: ['dotnet.wasm'],
            output: {
                esModule: false,
                format: 'cjs',
                compact: true
            }
        },
        outDir: outDir
    }
}));

Now in my webworker I import the modified dotnet.js, and an odd startup:

importScripts('./dotnet.js');
async function main() {
    const monoCfg = await firstMessagePromise;
    const dotnet = self.dotnet.dotnet;
    dotnet.moduleConfig.configSrc = null;
    const { setModuleImports, getAssemblyExports, } = await dotnet
        .withConfig(
            monoCfg
        )
        .create();
    await dotnet.run();
}
main();

And voilà.