[Blazor] Get rid of Blazor.boot.json and use a different strategy to flow the environment.

[javiercn]

Blazor webassembly environment can be configured through a response header on blazor.boot.json or directly within the call to Blazor.start in code. The environment typically flows from the ASPNETCORE_ENVIRONMENT on the server.

This approach is problematic because two reasons:

• We can't fingerprint blazor.boot.json the same way we do for other files (we can't leverage the importmap), and we always need to request it to the server bypassing the cache to ensure it's up to date (because it's not fingerprinted).
• Setting a header for blazor.boot.json is not always possible in standalone scenarios (like when hosting on Github pages), it's also environment dependent and hard to do.

We want blazor.boot.json to become boot.js as when it's an ES6 module, it can be easily fingerprinted by an importmap on hosted scenarios as well as on standalone scenarios by rewriting index.html and using a servicer-worker.

We can write the environment directly inside boot.js and allow the app to override it in a couple of ways:

• We can use a comment in the document as we emit the initial response.
• We can use a meta tag in the head.

For standalone scenarios, we can read the environment from launchSettings.json during build and place it on boot.js and we can read/take the environment from an MSBuild property at publish time.

With this, we bypass issues like #25152 and we make it possible for the entire resource load chain to be fingerprinted, avoid having to make uncached requests, and have a simpler deployment independent mechanism for flowing the environment.

---

Implementation plan

• Create the feature as opt-in
• Update tests in SDK & aspnetcore repo tests to opt-in when the feature flows into the repo
• Make the feature opt-out
• Remove explicit opt-in from SDK & aspnetcore repo tests

[maraf]

A sample of boot.js

import * as runtimeModule from "./dotnet.runtime.js";
import * as nativeModule from "./dotnet.native.js";
import nativeWasm from "./dotnet.native.wasm";
import coreLibWasm from "./System.Private.CoreLib.wasm";
import interopJavaScriptWasm from "./System.Runtime.InteropServices.JavaScript.wasm";
import mainAssemblyWasm from "./MySampleApp.wasm";

export const config = {
  "mainAssemblyName": "MySampleApp.dll",
  "assets": [
    {
        name: "dotnet.runtime.js",
        moduleExports: runtimeModule,
        behavior: "js-module-runtime"
    },
    {
        name: "dotnet.native.js",
        moduleExports: nativeModule,
        behavior: "js-module-native"
    },
    {
        name: "dotnet.native.wasm",
        resolvedUrl: nativeWasm,
        hash: "...",
        behavior: "dotnetwasm"
    },
    {
        name: "System.Private.CoreLib.wasm",
        virtualPath: "System.Private.CoreLib.wasm",
        resolvedUrl: coreLibWasm,
        hash: "...",
        behavior: "assembly",
        isCore: true
    },
    {
        name: "System.Runtime.InteropServices.JavaScript.wasm",
        virtualPath: "System.Runtime.InteropServices.JavaScript.wasm",
        resolvedUrl: interopJavaScriptWasm,
        hash: "...",
        behavior: "assembly",
        isCore: true
    },
    {
        name: "MySampleApp.wasm",
        virtualPath: "MySampleApp.wasm",
        resolvedUrl: mainAssemblyWasm,
        hash: "...",
        behavior: "assembly"
    }
  ],
  "globalizationMode": "invariant"
}

In this shape, both webpack & rollup can be configured to treat .wasm imports as static files to fingerprint & copy to output directory. For building without javascript bundler in play, we can output javascript consts instead of imports for .wasm files. So there will be a MSBuild property for switching between modes.

-import nativeWasm from "./dotnet.native.wasm";
-import coreLibWasm from "./System.Private.CoreLib.wasm";
-import interopJavaScriptWasm from "./System.Runtime.InteropServices.JavaScript.wasm";
-import mainAssemblyWasm from "./MySampleApp.wasm";
+const nativeWasm = "/_framework/dotnet.native.wasm";
+const coreLibWasm = "/_framework/System.Private.CoreLib.wasm";
+const interopJavaScriptWasm = "/_framework/System.Runtime.InteropServices.JavaScript.wasm";
+const mainAssemblyWasm = "/_framework/MySampleApp.wasm";

The shape of the config object is up to consideration, this is what we currently support.

[pavelsavara]

The shape of the config object is up to consideration, this is what we currently support.

I think we also support the more dense shape with name:hash, right ?

    "jsModuleNative": {
-      "dotnet.native.pvtfqc5zg4.js": "sha256-BV+jiq5AAz8QOm12mgaURLuSAgk201zTAloqhtKSNhU="
+      "dotnet.native.pvtfqc5zg4.js": nativeWasm
    },

We could teach it that instead of hash, there is a ES6 module object. But I like the ability of the larger scheme to add other metadata to each asset.

In both cases we don't verify the integrity anymore. I guess that's OK for bundler, but I would love to have keep it working for non-bundled scenario.

[maraf]

In both cases we don't verify the integrity anymore. I guess that's OK for bundler, but I would love to have keep it working for non-bundled scenario.

The integrity will remain there. I omitted it here because it was created manually