Wasm Dev+Debug experience #24
Description
During TypeShim development it became apparent that the dev and debug experience for .NET wasm is still somewhat lacking.
This issue is to consider what could be done to help improve the debugging experience of these types of projects.
Debugging with a separate aspnet server project.
Debugging only seems to work when serving from the wasm project. When debugging through the ASP server, debugging fails to work.
The tooling also seems somewhat sensitive still, (e.g. dotnet/runtime#122201)
Developing with WasmBundlerFriendlyBootConfig is slow
With an npm project that uses a bundler, as is very common in the big frameworks, the wasm project can be integrated fully in the client project, which is very useful for deployment scenarios. However, it requires a dotnet publish to be updated, which is slow and does not produce debuggable assets.
- TODO: figure out if its possible at all to debug a wasm browser app thats been bundled into a react/vue app.
TypeShim (or an adjacent library?) could help improve the dev experience by enabling switchable configurations where in debug the wasm bundle is loaded 'browser friendly' and in a production build the wasm bundle is included 'bundler friendly'.