• Users should be able to rely on standard JS idioms (import statements) to consume Blazor JS assets.
• Our build system should be able to produce an output layout that can easily be consumed by JS tools.
  • For example, adding a package.json to the project and calling an npm script after Blazor's build/publish steps.
  • This might simply mean we offer the option to link Blazor outputs into the dist/(Debug|Release) folders.

Items

• Generate ES module bundles that can be consumed via import statements.
  • Our modules should not pollute the global state (by default).
• Blazor web will have a base layer and separate chunks for enhanced nav, server interactivity, and wasm interactivity. Other Blazor flavors will be a single bundle.
• Update the wasm loading strategy to rely on standard JS idioms that toolchains can understand with enough flexibility to adapt to different bundlers.
  • Standard import. E.g. import { Blazor } from 'blazor'
  • Import as URL. E.g. import system from './_framework/system.wasm?url' (then we do fetch(system.url) or similar to load the asset).
  • Fetch (we don't include an import, and inside the loader we use fetch directly to load the asset).