I have the lastest Aurelia CLI and created a new dotnet core project with au new
. It fires up fine with dotnet run
and see the HMR in the browser console update and in the cmd console. However, the files are not actually updating even after the refresh. I can re-run dotnet run
and see after it finishes building that the files are updated. It’s almost like the webpack is not re-building the files. Anyone else have this issue? Note that I also had to change my script tags in the Index.cshtml to for the src files to reference correctly. I have not really had much luck with Aurelia CLI’s dotnet templates for some time now.
Ok so I ran across another CLI post (Using Aurelia CLI with Visual Studio (again)) and modified the webpack.config.js as noted (and changed the Index.cshtml file back to original) and it will run successfully. The only issue I’m seeing at this point is the page is not reloading after any view (.html) changes. I can see HMR updating in the browser console but it’s not updating the view. I can modify a .js file and it will reload but with any .html file changes it will not reload the page nor does HMR work. Any ideas there??
I will spin up a solution and tell you what I see
Thanks @brandonseydel. I can always fall back on running au run
but would be nice to just use dotnet run
or Debug as that eliminates a step.
I have the same problem. I find that it happens when i have devtools open. If i close devtools when making changes to the code then it updates normally.
Good luck remembering to close devtools before making each code change!
How do you get au run to work with the local aspnet webapi server running on say localhost:5001 and the client on localhost:9000?
Here is my experience:
Using Chrome (Version 72.0.3626.96 (Official Build) (64-bit)) and starting with DevTools open.
Using ‘dotnet run’
- ‘dotnet run’ gives 404 on vendor.css, but the app runs.
- On making a change to any view .html file (and saving) the HMR bundle rebuilds and the browser auto-refreshes.
- Close DevTools and re-open dev tools (F-12), make a change to the view .html file and saving gives:
Unhandled rejection Error: No ValueConverter named “upper” was found!
Making a change to a controller .cs requires re-build.
Using ‘dotnet watch run’
Build output gives fail:
fail: Microsoft.AspNetCore.NodeServices[0]
clean-webpack-plugin: C:\Users\{username}{application_path}\wwwroot\dist has been removed.
and in dev tools…
GET https://localhost:5001/__webpack_hmr net::ERR_CONNECTION_RESET 200 (OK)
Further to my previous post, I have just tried with the template that I use. I do not usually ‘watch’ code when developing (I simply build or debug manually), so I tried to use ‘dotnet watch run’ and ‘au build --watch’ together, and it worked fine. Any changes to either controller .cs files or any Aurelia app .ts files are visible immediately on refresh. Though, I do concede this template is configured a little differently, with the Aurelia app and dotnet sit side by side with no Webpack dev middleware.
Can I ask what IDE you use and how, ideally, you would like the template to work?
In our team we use more than Visual Studio such as VS Code and Webstorm. In theory it shouldn’t really matter what IDE we use since you can use dotnet CLI to run your builds. Ideally we want the template to run just like is expected were you can run dotnet run
and it will build .net side and node side with watching src files. It mostly works now with the aforementioned webpack.config.js fix (which resolved the incorrect ref src files in Index.cshtml) and does refresh the browser on JS changes but not HTML which I’m assuming has something to do with the C# HMR implementation since it does work with au run --watch
.
For the CLI template I chose…
- ESNext
- Webpack
- HTTP/1.1
- ASP.NET Core
- Babel
- Max minification
- Sass
- Jest
- Protractor
- No editor
- None (no scaffolded features)
Update: I’ve merged in my existing src files which uses the app file (js/html) as a “layout” with the <route-view />
and whenever I modify any HTML views that are rendered inside that route-view, HMR works fine. If I change the app.html, nothing happens other than I see the update log in the browsers console. Also If I change my nav or footer, which are components inside my app.html (not routed) it updates that component but then my route-view content disappears. Weird but I’m thinking that has more to do with how HMR is working with aurelia. I can deal with that easy enough since the devs will 99% of the time be working in the routed views and will work fine for them.
I believe this is a known limitation for the current HMR. Editing app.html/ts/js doesn’t quite work properly.
I agree with everything you said, in fact, I have said the same thing in past posts. This is why I created my own templates.
The dotnet template has ‘Home/Index’ view that contains the <div aurelia-app="main">
. This also has a scripts section that looks like this (aurelia-cli v1.0.0-beta.13):
@{
ViewData["Title"] = "Home Page";
}
<div aurelia-app="main">Loading...</div>
@section scripts {
<environment names="Production">
<script type="text/javascript" asp-src-include="~/dist/common.*.chunk.js" asp-append-version="true"></script>
</environment>
<environment names="Development, Staging, Production">
<script type="text/javascript" asp-src-include="~/dist/vendor.*.chunk.js" asp-append-version="true"></script>
</environment>
<environment names="Development">
<script type="text/javascript" src="~/dist/app.bundle.js" asp-append-version="true"></script>
</environment>
<environment names="Staging, Production">
<script type="text/javascript" asp-src-include="~/dist/app.*.bundle.js" asp-append-version="true"></script>
</environment>
}
The scripts that are compiled to not look like ~/dist/app.bundle.js"
. So the quickest way to make this work (that I have found) is to change the <environment names="Development">
to look like this:
<environment names="Development">
<script type="text/javascript" asp-src-include="~/dist/*.bundle.js" asp-append-version="true"></script>
<script type="text/javascript" asp-src-include="~/dist/*.chunk.js" asp-append-version="true"></script>
</environment>
Now, ‘dotnet run’ should serve the app from the Home/Index
view. You can verify this by making a change to the content by adding a <h1>Index View</h1>
tag or something to show this.
When using au run
the Aurelia app is served from the result of the index.ejs
template being processed by a HtmlWebpackPlugin.
So in short, from a new CLI project with the specifications in your last post, changing the script references in the Home/Index
view is the fastest way to fix this issue.
H̶e̶r̶e̶ ̶i̶s̶ ̶t̶h̶e̶ ̶t̶e̶m̶p̶l̶a̶t̶e̶ ̶(̶o̶f̶ ̶t̶h̶e̶ ̶s̶p̶e̶c̶i̶f̶i̶c̶a̶t̶i̶o̶n̶ ̶o̶u̶t̶l̶i̶n̶e̶d̶ ̶b̶y̶ ̶@̶r̶k̶e̶v̶e̶r̶ ̶a̶b̶o̶v̶e̶)̶ ̶w̶i̶t̶h̶ ̶a̶l̶l̶ ̶i̶s̶s̶u̶e̶s̶ ̶t̶h̶a̶t̶ ̶I̶ ̶m̶e̶n̶t̶i̶o̶n̶e̶d̶ ̶i̶n̶ ̶t̶h̶i̶s̶ ̶t̶h̶r̶e̶a̶d̶ ̶f̶i̶x̶e̶d̶.̶ ̶ ̶
T̶h̶e̶ ̶t̶e̶m̶p̶l̶a̶t̶e̶ ̶b̶u̶i̶l̶d̶s̶ ̶a̶n̶d̶ ̶r̶u̶n̶s̶ ̶i̶n̶ ̶b̶o̶t̶h̶ ̶’̶a̶u̶ ̶r̶u̶n̶’̶ ̶a̶n̶d̶ ̶’̶d̶o̶t̶n̶e̶t̶ ̶r̶u̶n̶’̶ ̶w̶i̶t̶h̶o̶u̶t̶ ̶i̶s̶s̶u̶e̶.̶ ̶H̶M̶R̶ ̶w̶o̶r̶k̶s̶ ̶w̶h̶e̶n̶ ̶r̶u̶n̶n̶i̶n̶g̶ ̶i̶n̶ ̶b̶o̶t̶h̶ ̶t̶h̶e̶ ̶A̶u̶r̶e̶l̶i̶a̶ ̶C̶L̶I̶ ̶a̶n̶d̶ ̶t̶h̶e̶ ̶N̶E̶T̶ ̶C̶o̶r̶e̶ ̶C̶L̶I̶ ̶T̶o̶o̶l̶s̶.̶ ̶ ̶
I spent some time today looking at this and found that, although the modules are now served from the mvc controller and update with HMR through the controller, and all seemed well at first, after a short while this actually causes a refresh loop in the browser.
The only way I have found to use HMR or ‘watch’ like functionality is to use both the dotnet and Aurelia watch implementations in parallel without the WebpackDevMiddleware. Having never used these (by choice) before, I have never run into these HMR issues.
I’ve been using the app now and HMR is really buggy, at least in the Aurelia CLI .net core implementation. I don’t know what the culprit is but I’d rather just disable HMR all together and just have it refresh. I can’t figure out how to make that work though. I’ve tried commenting out the HMR code in startup.cs but no luck. Any help??
I think it’s some config in either webpack.config.js or package.json run command, or the run task in Aurelia project, maybe try disable there?
I have looked in to this further and there are many issues. I find more every time I try something new. The HMR refresh looping crops up often when attempting various mitigations.
What we require are project starting points that are simple, transparently understandable and do not attempt to provide too much all at once. I am currently working on .NET templates (and the delivery thereof) and will post more soon.
Really what all that is trying to accomplish is providing the developer a single command to run all builds (C# and client-side transcompiling) AND watch files and update on changes. I know HMR is new and has a few bugs/hiccups and have witnessed that myself. It’s a great idea but not a huge deal for my browser to refresh as it does so usually before I even get back to the browser from my IDE. What I ended up doing was removing HMR from the Startup.cs and added the webpack BrowserSyncPlugin. Now it just refreshes the browser for any C# or client-side file change. I know that I loose current state but for our senario it’s not ever been much of an issue since we often have to account for that anyways since a user can be redirected to SSO and then back again so we have to keep state anyways.
I’m okay with leaving out HMR for now and will keep an eye on it to see if the issues resolve. Oh…on a side note, I had also noticed an issue with HMR working improperly with child route refreshes.