[browser] Unnecessary browser and node calls breaking usage in restricted environments

[elringus]

I'm trying to build .NET 8 library for VS Code web extension, where neither browser APIs (window/document), nor node modules are available. Previously (in .NET 6) I had to strip generated JS wrapper from various unconditional usages of such APIs. I hoped in .NET 8 it's solved (and I can see lots of changes in this direction), but unfortunately there are stilll issues. For example, createDotnetRuntime function has following (from bundled library sources, so it's bit mangled):

document is undefined in VS Code and require('url') causes exception. I'm injecting all the requires resources (runtime.wasm, dotnet.runtime.js, etc) via the assets in config, so no IO should be required to boot the runtime.

Is it possible to guard browser/node-specific calls like this for .NET 8?

The Specific Offenders in .NET 8

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.

[ghost]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I'm trying to build .NET 8 library for VS Code web extension, where neither browser APIs (window/document), nor node modules are available. Previously (in .NET 6) I had to strip generated JS wrapper from various unconditional usages of such APIs. I hoped in .NET 8 it's solved (and I can see lots of changes in this direction), but unfortunately there are stilll issues. For example, createDotnetRuntime function has following (from bundled library sources, so it's bit mangled):

document is undefined in VS Code and require('url') causes exception. I'm injecting all the requires resources (runtime.wasm, dotnet.runtime.js, etc) via the assets in config, so no IO should be required to boot the runtime.

Is it possible to guard browser/node-specific calls like this for .NET 8?

Reproduction Steps

Install the VS Code extension and notice Cannot load module 'url'. error in the developer console.

Remove require('url') in createDotnetRuntime funtion, repack the extension and notice that the error is gone.

Expected behavior

No calls to browser or node-specific APIs (eg, window, document, new URL, require(...), etc) are performed when all the required dotnet assets are specified in config.

Actual behavior

Browser and node-specific APIs are used even when all the required dotnet assets are specified in config.

Regression?

No response

Known Workarounds

No response

Configuration

.NET 8.0.0-rc.2.23431.9

Other information

No response

Author:	Elringus
Assignees:	-
Labels:	area-Meta, untriaged
Milestone:	-

[elringus]

Trying to find the culprit in the sources, but stuck here: https://github.com/dotnet/runtime/blob/main/src/mono/wasm/runtime/es6/dotnet.es6.lib.js#L60

There are no other " _scriptDir" vars in the codebase, so it must be it, but not sure where require('url') comes from.

[ghost]

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

Issue Details

---

Description

I'm trying to build .NET 8 library for VS Code web extension, where neither browser APIs (window/document), nor node modules are available. Previously (in .NET 6) I had to strip generated JS wrapper from various unconditional usages of such APIs. I hoped in .NET 8 it's solved (and I can see lots of changes in this direction), but unfortunately there are stilll issues. For example, createDotnetRuntime function has following (from bundled library sources, so it's bit mangled):

document is undefined in VS Code and require('url') causes exception. I'm injecting all the requires resources (runtime.wasm, dotnet.runtime.js, etc) via the assets in config, so no IO should be required to boot the runtime.

Is it possible to guard browser/node-specific calls like this for .NET 8?

Reproduction Steps

Install the VS Code extension and notice Cannot load module 'url'. error in the developer console.

Remove require('url') in createDotnetRuntime funtion, repack the extension and notice that the error is gone.

Expected behavior

No calls to browser or node-specific APIs (eg, window, document, new URL, require(...), etc) are performed when all the required dotnet assets are specified in config.

Actual behavior

Browser and node-specific APIs are used even when all the required dotnet assets are specified in config.

Regression?

No response

Known Workarounds

No response

Configuration

.NET 8.0.0-rc.2.23431.9

Other information

No response

Author:	Elringus
Assignees:	-
Labels:	arch-wasm, area-Meta, untriaged
Milestone:	-

[radical]

cc @pavelsavara @maraf

[pavelsavara]

require in the emscripten code is quite annoying.
Perhaps it would go away if you pass

  <PropertyGroup>
     <EmccEnvironment>web,worker</EmccEnvironment>
  </PropertyGroup>

But that would make it node incompatible.

For the import.meta.url I thought we solved it by #90392
We are not going back to CJS.

[elringus]

But that would make it node incompatible.

I hope we can me it work in both node, browser and restricted environments w/o special builds for each. This is already working on my end with those 3 modifications I've mentioned above.

For the import.meta.url I thought we solved it by #90392

Yeah, that was essential, but not enough for VS Code, unfortunately (sorry I wasn't able to test at the time, had to rewrite the whole library for .NET 8 and new interop). If those 3 calls to import.meta and new URL could be guarded somehow, it would solve the issue completely. The workaround with stripping them on build post-process will work for the time being.

[pavelsavara]

Yeah, that was essential, but not enough for VS Code

Could you please point me to more details about VS Code constraints ? Documentation ?

[elringus]

Here: https://code.visualstudio.com/api/extension-guides/web-extensions#migrate-extension-with-code

Due to V8 cache not available on node (and dotnet runtime requiring it), we also have to use the web format for standalone VS Code environment. Basically, we can't use any import/require, except the pre-defined vscode, which provide limited VS Code API. Also, no window/documents, etc browser-specific stuff.

[pavelsavara]

Due to V8 cache not available on node (and dotnet runtime requiring it)

Cache API ? This should disable it.

dotnet
    .withConfig({
        cacheBootResources: false,
    })

[elringus]

Presumably it's something about v8 code caching: https://v8.dev/blog/code-caching I didn't really investigate it properly. Just had invalid host defined options error when attempted to run the extension in node and prompt googling showed that it's because of the cache API not available in modules. The extension I'm working on works fine in web anyway, so I don't really need it.

[pavelsavara]

Could you please update the top level description and list specific offenders ? That would make at least some of them more actionable.

[elringus]

Done. Thanks for looking into this!

[pavelsavara]

Migrated into #80045