I know there are other solutions to working with Aurelia + ASP.NET Core + HtmlWebpackPlugin, but I had a slightly different requirement – I wanted to use HtmlWebpackPlugin AND Razor (.cshtml) files at the same time.
I ended up writing this blog post to explain the gist, and then applied my findings to my Aurelia project.
And since I’m fully using HtmlWebpackPugin, the webpack.netcore.config.js file is no longer required.
I feel like the end result is better and more simple.
disable minification of cshtml (minify: false) otherwise you’ll have a surprise in production
I ended up not using RuntimeCompilation at all - you don’t need it while developing - VS will rebuild the project. For the production workflow I’m using a TeamCity build step which runs webpack BEFORE the core project is built. This way Index.cshtml is correct for the msbuild to pick it.
there is no much value in using UseWebpackDevMiddleware, even worse - every change in controllers will trigger a webpack task. You’re going to suffer on bigger projects Instead run a webpack watch task in background while developing. Yes, you loose HMR, but it’s a minor inconvenience.
disable minification of cshtml ( minify: false ) otherwise you’ll have a surprise in production
I forgot to commit the minify fix. Definitely got caught by that one.
I ended up not using RuntimeCompilation at all - you don’t need it while developing - VS will rebuild the project.
I’m sorry, but I don’t quite understand that statement.
For the production workflow I’m using a TeamCity build step which runs webpack BEFORE the core project is built. This way Index.cshtml is correct for the msbuild to pick it.
But what about at dev time? I feel like I’m not understanding something in your process (I haven’t studied your templates in depth).
What I like is the ability to use F5 to build the application, launch the web server, and still gives us HMR… all with a single key stroke. I understand the trade off is that “every change in controllers will trigger a webpack task”, but it seems like a simplified setup and dev experience compared to what you’re suggesting. Also, it seems like we’re usually either working on the front end OR the back end… it’s not often that we’re working on both at the same time. Also, HMR is pretty important for us. And don’t forget https://webpack.js.org/plugins/dll-plugin/ can be used to greatly increase the webpack compilation speed.
Let’s keep this conversation going if you don’t mind. I want to understand your perspective and definitely want to use the best setup for our needs.
I don’t really get what problem RuntimeCompilation solves. During production Index.cshtml is compiled with the correct links and does not change. During dev you get Razor recompiled by default.
My UI and Api are usually developed in parallel which is why webpack recompilation at every build is extremely annoying and slow. Moreover, I’ve found that HMR does not work when form validation is involved - weird crashes in console log which I did not have desire to chase. So, my dev workflow now is to start webpack --mode development --watch in a console via npm. If I change anything in Api the build is super fast. If I change anything in UI browser refresh pulls the latest.
I used to use dll-plugin as well but removed it because, as I mentioned before, HMR does not work anyway with validation, plus it creates an additional complexity in webpack configuration.
On a side note, you should also disable caching on an index page, otherwise clients will keep getting the old code after an upgrade.
This is precisely the approach I took with one of the Visual Studio extension templates a few months ago. Regeneration of the hashed .js file references via the .ejs template ensures the correct updated files are loaded.
Also one problem might be setting up differential loading or something alike and then have a template to pick up the different scripts. Razor is one way of enumerating JS files and pick them up, especially with live reload.