Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Overall, Feature #59456 - Get rid of Blazor.boot.json has improved load times and reduced network requests.

However, one consequence of embedding the blazor.boot.json manifest internally to a dotnet.*.js file , is that the manifest can only be extracted by build tools using text matching methods from the js file, which is not robust.

Blazor.boot.json has previously been available from the file system, and provided a reliable json model and manifest list of framework files, that could provide the authoritative source for bundling and compression lists. ( Bundling is absolutely essential for resource constrained or api limited targetted systems)

Describe the solution you'd like

The manifest file (blazor.boot.json) was, previously to Net10, an external document available for use especially by build and deployment tools.

Continue to make the manifest document readily available. This could be by:

1. A build option, e.g OutputManifestToFileSystem, expected to be placed under the new tag OverrideHtmlAssetPlaceholders. This tag will mean 'also', so the manifest will continue to be copied to dotnet.*.js, if opted in, and also to file system (as per previous behaviour)

2. Or: Formalise the text parameters around the embedded file, within dotnet.*.js. Currently I need to use 'withConfig' and /json-end/ to extract. This option is less desirable but easier maybe.
   One technique I have used is to place the string in a javascript function - in this way the boundary is the javascript function name, so there is some protection about the text boundary being changed (by your team):
   function BlazorBootJson() {
   return '{...}';
   }

ie Tt.withConfig(BlazorBootJson());

Yeh, 2 is not great. Maybe 1.

Additional context

Many Blazor systems and particularly WebAssembly variants are deployed to locked down and/or resource constrained environments. There are a number of Enterprise systems (even from Microsoft) that have many limits, including web resource constraints to 5MB, files limited only to html and js, and concurrent api throttling limits (which can easily be hit by a call centre opening at 9:00AM, for example)

Bundling (meaning grouping, compression and embedding), is essential to these deployments, and reading the blazor.boot.json as the authoritative list is a crucial part of this tooling.

I suggest that blazor.boot.json be considered an 'external' type document, with a known json model that is in use out in the wild.

Slightly off-topic: can I also suggest you be very cautious about changing the Blazor.Start overrides, if at all. It works extremely well as is, especially with the caching of the Wasm assemblies, and it is essential to my application and I would expect a lot of other people's as well.
I will emphasise again how well it works: I have never seen it ask for a file it did not have already, and when it does make a request, it reliably waits for all of the cache lookups and in depth api calls that I tack onto the process. Its good!