Smooth out support for running .NET from JS via WebAssembly

[danroth27]

A common scenario for running .NET on WebAssembly is when you want to reuse a .NET library from an existing JS app. In this scenario, the user isn't creating an app from scratch. Instead they are integrating a .NET library into an existing JS based app, like an Angular/React/Vue app that will run in a browser or in a Node.js based app.

Since the app is preexisting, it already has a defined dev workflow. For example, many frontend JS frameworks use an NPM and WebPack based build system and the WebPack dev server for hosting the app locally. Any .NET code needs to be integrated into existing HTML and JS files and hosted as static web assets along with the rest of the JS app.

Some issues that could be addressed to make this experience better:

• The WasmMainJSPath property is currently required even though a main.js file might not be needed. The user may be importing dotnet.js directly into their existing app. It seems like this property should be optional.
• An HTML file is currently always generated for the app, even though in existing JS apps the host HTML files likely already exist. Generating this file should probably be optional.
• The project must currently be <OutputType>Exe</OutputType> and a main entry point is currently required. For calling into a .NET library from JS it seems like a library project should be allowed. [browser] Suport for OutputType Library #89577
• We should consider making dotnet.js available from NPM. We've had similar requests for the Blazor scripts: Publish blazor.*.js files to npm aspnetcore#10124.

.NET application bundle should be friendly to javascript bundlers

• Provide an MSBuild property that switches boot config URLs to imports [Blazor] Get rid of Blazor.boot.json and use a different strategy to flow the environment. aspnetcore#59456 (comment)
• We need to change the boot config schema to allow to use to put more metadata to each item (resolved urls, module exports, friendly, fingerprinting and plain names, etc)
• Bundlers will have an easier work if we imports various modules directly, not via configuration from boot config. The problem is that importmaps are not always present in HTML document, but some modules are always fingerprinted. We would probably have ship two flavours of dotnet.js module - one imports from boot config and another with hardcoded imports relaying on importmap to redirect to fingerprinted asset

Additional tasks

• Application environment has an exception from config precedence order (boot config over javascript API). We should unify the precedence (probably javascript API over boot config)

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

---

A common scenario for running .NET on WebAssembly is when you want to reuse a .NET library from an existing JS app. In this scenario, the user isn't creating an app from scratch. Instead they are integrating a .NET library into an existing JS based app, like an Angular/React/Vue app that will run in a browser or in a Node.js based app.

Since the app is preexisting, it already has a defined dev workflow. For example, many frontend JS frameworks use an NPM and WebPack based build system and the WebPack dev server for hosting the app locally. Any .NET code needs to be integrated into existing HTML and JS files and hosted as static web assets along with the rest of the JS app.

Some issues that could be addressed to make this experience better:

• The WasmMainJSPath property is currently required even though a main.js file might not be needed. The user may be importing dotnet.js directly into their existing app. It seems like this property should be optional.
• An HTML file is currently always generated for the app, even though in existing JS apps the host HTML files likely already exist. Generating this file should probably be optional.
• The project must currently be <OutputType>Exe</OutputType> and a main entry point is currently required. For calling into a .NET library from JS it seems like a library project should be allowed.
• We should consider making dotnet.js available from NPM. We've had similar requests for the Blazor scripts: Publish blazor.*.js files to npm aspnetcore#10124.

Author:	danroth27
Assignees:	-
Labels:	arch-wasm, untriaged, area-Build-mono
Milestone:	-

[radical]

The project must currently be Exe and a main entry point is currently required. For calling into a .NET library from JS it seems like a library project should be allowed.

We could use either OutputType=Library, or some new property to indicate the case where the output bundle doesn't need to have a main js, or index.html .

[maraf]

I'm working on a sample of integrating a .NET library into a react component wrapped as npm package and installed into a target react application.

https://github.com/maraf/dotnet-wasm-react

[maraf]

Moving the rest of items to .NET 9