Ideas for improvement of dev inner loop with scoped CSS development and dotnet watch run

One of the more tedious tasks in building any app is of course the endless cycle of tinkering for the correct shade of grey for that input border. Scoped CSS is really, really great! But after extensively using dotnet watch run for building a Blazor WebAssembly app, let’s just say we have had ample time to think of some improvements in the development inner loop in this area 😃.

1. Make ‘dotnet watch run’ smarter for the type of file that is changed. For CSS file change, only a few tasks need to run, not the full build pipeline. Furthermore, only the touched scoped css files could be diffed into the generated CSS file, without gobbling / touching the other files.
2. Scoped CSS file is just a file, it doesn’t need a full host restart. Just set the correct headers to force reload of that file and trigger refresh, but not a restart of the whole host.
3. A huge, huge time saver would be the possibility to directly edit scoped CSS files the browser DEV tools back to razor.css file using a map file like TypeScript files via the Filesystem in the Sources tab.

See also: https://github.com/dotnet/aspnetcore/issues/27270

[Peluko]

Perfect. Meanwhile I finally figured out how to get Hot Module Replacement working right.

During development I have running:

• Dart Sass watch for converting component’s SCSS files to CSS
• dotnet watch msbuild for generating the scoped CSS and the .Net DLLs
• Wevpack dev server with HMR enabled. It compiles Typescript and bundles scoped CSS along with global CSS

On the browser I keep opened the Webpack dev server proxied page and whenever I touch a CSS, it is compiled by SASS, then by msbuild and finally Webpack loads it on the browser without reloading the page. It takes less than a second from modifying CSS to get results on the browser.

To keep the app running I use the usual VSCode launch task without the pre-dependency on the build step, because the project i s already builded due to the dotnet watch. I think that with VS2019 should be almost the same. Also I’ve set VSCode to not open browser on launch, because the whole thing is about keeping the browser always opened and up to date.

Also I’ve set on Program.cs a code to touch a file on the wwwroot folder whenever the app is restarted. This way the Webpack dev server reloads the browser when I change the .Net code.

The final result is the same as working with dotnet watch run but with CSS HMR added for all CSS editin. But for working with .Net code you use the normal edit-F5-test cycle. If you use a normal dotnet watch run for .Net code, the app is restarted also on CSS editing, losing the HMR capabilities. Of course, you can use a normal dotnet watch run if you are not going to touch the CSS files.

[javiercn]

We already stitch the files for bundling using imports for things coming from packages and referenced projects. The only thing we need to do here is to call the bundle target when a scoped css file changes and the Razor compiler when you add a new scoped css file to add the scope attribute to the generated markup.

It might be possible that this is achievable today with dotnet watch using custom commands (passing the target to invoke if it supports multiple targets and adding additional files to watch in MSBuild)

files to watch

dotnet watch msbuild /t:BundleScopedCssFiles