-
Notifications
You must be signed in to change notification settings - Fork 10.3k
[Blazor] Get rid of Blazor.boot.json and use a different strategy to flow the environment. #59456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
A sample of 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 -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. |
I think we also support the more dense shape with "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. |
The integrity will remain there. I omitted it here because it was created manually |
Being friendly to javascript bundlers is moved to dotnet/runtime#77191 |
Blazor webassembly environment can be configured through a response header on
blazor.boot.json
or directly within the call toBlazor.start
in code. The environment typically flows from theASPNETCORE_ENVIRONMENT
on the server.This approach is problematic because two reasons:
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).We want blazor.boot.json to become
boot.js
as when it's an ES6 module, it can be easily fingerprinted by animportmap
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:For standalone scenarios, we can read the environment from
launchSettings.json
during build and place it onboot.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
The text was updated successfully, but these errors were encountered: