[wasm] Tracking issue for build/bundler changes

[radical]

Implementation plan

• Split Wasm SDK in the SDK repo (Split WebAssembly SDK from Blazor SDK sdk#31154)
• Move Wasm SDK to the runtime repo
  • Add KnownWebAssemblySdkPack to GenerateBundledVersions installer#15951
  • Add KnownWebAssemblySdkPack to GenerateBundledVersions for .NET 6 and 7 installer#16159
  • [browser] Wasm SDK packed as a nuget package #84761
  • [browser] Integrate compression from StaticWebAssets #84924
  • Wasm SDK packed as a nuget package sdk#31519
  • Produce a fixed Wasm SDK pack version that is backward compatible for Blazor in .NET 6 and 7
• Update runtime to be able to use Wasm SDK
  • [browser] Minimal blazor.boot.json integration #84296
• Update Blazor to use new runtime startup
  • [browser] Split dotnet.js and introduce loader + emscripten modules #85045
  • Disable dotnet.js fingerprinting for .NET 8 sdk#31829
  • [blazor] Boot handled by dotnet.js aspnetcore#47752
• Integrate Wasm SDK with runtime
  • [browser] Wasm SDK task tests #85764
  • Library tests
  • Wasm.Build.Tests
  • E2E tests for features integrated from blazor
  • Templates
    • Browser
      • [browser] Integrate DevServer into WasmAppHost #88985
    • Console [browser] Migrate wasmconsole template to WebAssembly SDK #102743
      • Configurable wwwroot for StaticWebAssets sdk#34178
      • Set the static web assests path to public
  • Embed all mono-config settings in boot.json
• [browser] Wasm SDK tests #86087

Deployment scenarios

Deployment shapes

• Smallest possible loader + emscripten.js X one dotnet.js
• Inlined config in loader X separate config file
• Dlls/webcil and other assets X memory snapshot

It will cover various needs

• NPM/react/etc integration: "we want single file that is webpack friendly"
• Blazor leaves config loading to runtime, but doesn't loose perf boost from not waiting on dotnet.js download
• Separate assets beter utilize HTTP cache

Browser vs Wasi

• The same SDK Microsoft.NET.Sdk.WebAssembly.Pack
  • All the code could probably be ported to existing runtime sdk
• Trigger by RID browser-wasm x wasi-wasm
  • RID defaults to browser-wasm
• Shares a common package Microsoft.NET.Sdk.WebAssembly.Pack
  • Differences based on RID, can possibly split the package in the future

Browser SDK responsibilities

StaticWebAssets SDK <- (Runtime) Wasm SDK <- Blazor SDK

• StaticWebAssets SDK
  • FileFingerPrinting
  • BrotliCompress
  • GzipCompress
• Wasm SDK
  • BootJson
  • ServiceWorker
  • GetFileHash
  • AppSettings.json
  • BlazorWasm.web.config
  • Bundle transformation + ResourceLoader
• Blazor SDK
  • BlazorTrimming
  • Blazor specific config bits

From blazor

• Add compression step like blazor
  • Move asset compression to the Static Web Assets SDK from the Blazor Webassembly SDK aspnetcore#46998
• Hashing
  • [browser] wasm memory snapshot into browser cache #82049
  • Move integrity support to the Static Web Assets SDK from the Blazor WebAssembly SDK aspnetcore#47000
• Cache busting [wasm] implement browser cache busting for JSHost.ImportAsync #74815
• Download appSettings (WebAssemblyConfigLoader)
  • Requires C# API
  • Blazor owns the configuration builder, but in vanilla wasm we don't have that concept built-in
  • Probably we should offer an extension method on top of configuration builder or we should add the files to VFS
  • => We should just enable to get to the files, don't process them by default. VFS seems like the ideal solution
• Lazy loading
  • Requires C# API or we can provide partial support by putting the JS code into INTERNAL and let blazor only define an JSImport
• CacheBootResources
• SatelliteResources
  • Requires C# API or we can provide partial support by putting the JS code into INTERNAL and let blazor only define an JSImport
  • Blazor loads only current culture + ancestors, it requires calling into .NET to get culture hierarchy
  • At the moment we by pass this by loading all satellite resources
• JS initializers
  • Requires to share the definition with blazor
  • Blazor has their own callbacks and we should have our own

others

• Allow Blazor's build to be able to extend wasm sdk one
• And same for wasi
• split it into configurable steps
• Support picking up items from @(Content) etc
• Deploy dotnet.js.symbols
• NPM package friendly
• anti-virus friendly
• able to deploy .js files too, including workers
• [wasm] Make WasmMainJSPath optional #63465
• Smooth out support for running .NET from JS via WebAssembly #77191
• [wasm] wasm-experimental: dotnet publish with output directory doesn't put the AppBundle in the output directory #83760

JS startup

• [wasm] Design application startup, template, configuration #70892
• Adopt blazor.boot.json like format, instead of mono-config.json
• runtimeconfig.json/.bin vs launchsettings

[ghost]

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

Issue Details

---

TODO

• add compression step like blazor
• Adopt blazor.boot.json like format, instead of mono-config.json
• Allow Blazor's build to be able to extend wasm sdk one
• And same for wasi
• split it into configurable steps

Author:	radical
Assignees:	radical
Labels:	arch-wasm, area-Build-mono
Milestone:	7.0.0

[pavelsavara]

I don't understand the WASI requirement. It is closer to mono on windows than to mono on the browser.
There is no JS, no fetch, no downloading stuff, no Emscripten to configure. @lewing

[radical]

re:wasi, idea is to be able to support building for that also, with our toolchain.

[lewing]

The wasi bundler embeds the assemblies, we should enable that option on wasm as well.

[radical]

I would suggest adding your name against the item that you are working on.

[radical]

The remaining bits are all for milestone 9.0 .

[maraf]

Closing this issue as remaining tasks are tracked individual issues