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.

I have javascript interops to js codebehind in my blazor c# code. Builds always result in the JSImport code-generator creating new unique code, and as such the compiled output cannot be deterministic, making verifiable source code impossible, which for open source financial webapps in particular is critical. To work around this, I've statically incorporated the JSImport auto-generated code by copying it into the original source code, and then commenting out the JSImport attributes so that the code remains static (to locate the auto-generated code, build, then right click a method marked with JSImport and in the submenu select 'go to definition', and this will take you to the auto-generated cs code). Takes a little bit of easy finagling to make it work, such as annotating with
[method: SupportedOSPlatform("browser")]
where needed, and then adding ! to variables creating null warnings and then finally making the JSFunctionBinding nullable (append ? to the type)

This is of course a maintenance nightmare but it does work and I now get repeatable binary matches on the output wasms, as long as I build or publish with these flags set:
dotnet publish /p:BlazorWebAssemblyEnableLinking=true /p:Optimize=true /p:ContinuousIntegrationBuild=true /p:Deterministic=true /p:ReproducibleBuild=true

Describe the solution you'd like

Whatever randomness is imposed by JSImport code generation could probably become deterministic, and possibly even smart enough to know if the code generator even needs to activate if the source hasn't changed (source hash checksum embedded in previously generated code?). This would restore native deterministic builds and hence provable source code, without the need for my kludgey workaround.

I'd also like to suggest making the default build parameters to always produce code-based (not filestamp or path) deterministic output so we don't need to hunt down all these confusing 'determinism' parameters to try to close the gap. Seems very complicated to achieve what should be intuitive, and I don't believe there's a practical or common need for compiling unchanged source producing different outputs with new hashes, especially as the default. I believe most developers instinctively associate the wasm hash with the exact contents of the source code alone, plus the cachebusting hash rationale doesn't add value from that context.

Additional context

Blazor is an amazing product folks, glad to see it reaching the maturity and robustness we've long awaited. Much respect