[wasm] Tracking issue for build/bundler changes

[radical]

Implementation plan

• [x] Split Wasm SDK in the SDK repo (https://github.com/dotnet/sdk/pull/31154)
• [x] Move Wasm SDK to the runtime repo
  • [x] https://github.com/dotnet/installer/pull/15951
  • [x] https://github.com/dotnet/installer/pull/16159
  • [x] https://github.com/dotnet/runtime/pull/84761
  • [x] https://github.com/dotnet/runtime/pull/84924
  • [x] https://github.com/dotnet/sdk/pull/31519
  • [x] ~Produce a fixed Wasm SDK pack version that is backward compatible for Blazor in .NET 6 and 7~
• [x] Update runtime to be able to use Wasm SDK
  • [x] https://github.com/dotnet/runtime/pull/84296
• [x] Update Blazor to use new runtime startup
  • [x] https://github.com/dotnet/runtime/issues/85045
  • [x] https://github.com/dotnet/sdk/pull/31829
  • [x] https://github.com/dotnet/aspnetcore/pull/47752
• [ ] Integrate Wasm SDK with runtime
  • [x] https://github.com/dotnet/runtime/pull/85764
  • [ ] Library tests
  • [x] Wasm.Build.Tests
  • [x] E2E tests for features integrated from blazor
  • [ ] Templates
  • [x] Browser
    • [x] https://github.com/dotnet/runtime/pull/88985
  • [ ] Console https://github.com/dotnet/runtime/issues/102743
    • [ ] https://github.com/dotnet/sdk/pull/34178
    • [ ] Set the static web assests path to public
  • [x] Embed all mono-config settings in boot.json
• [ ] https://github.com/dotnet/runtime/issues/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

• [x] Add compression step like blazor
  • https://github.com/dotnet/aspnetcore/issues/46998
• [ ] Hashing
  • https://github.com/dotnet/runtime/pull/82049
  • https://github.com/dotnet/aspnetcore/issues/47000
• [ ] Cache busting https://github.com/dotnet/runtime/issues/74815
• [x] 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
• [x] 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
• [x] CacheBootResources
• [x] 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
• [x] JS initializers
  • Requires to share the definition with blazor
  • Blazor has their own callbacks and we should have our own

others

• [x] Allow Blazor's build to be able to extend wasm sdk one
• [ ] And same for wasi
• [x] split it into configurable steps
• [x] Support picking up items from @(Content) etc
• [x] Deploy dotnet.js.symbols
• [ ] NPM package friendly
• [x] anti-virus friendly
• [x] able to deploy .js files too, including workers
• [x] https://github.com/dotnet/runtime/issues/63465
• [ ] https://github.com/dotnet/runtime/issues/77191
• [x] https://github.com/dotnet/runtime/issues/83760

JS startup

• [x] https://github.com/dotnet/runtime/issues/70892
• [x] 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