Repository navigation
slow using dotnet watch run #545
Description
I've set up a small project and so far most everything seems to work fine. My project uses the csproj model and for the frontend I've got Vue running (thanks to some resources I found here and elsewhere). HMR is pretty fast, but I'm not sure how you guys intend for people to run the server during development. I've got it set up to use dotnet watch run so I don't have to restart the server manually after backend code changes. The problem is everytime you do dotnet run, webpack has to set itself up again from scratch, so you can imagine how dotnet watch run feels.
I'm fairly new to node and especially webpack, but a complete noob when it comes to dotnet core + node. I wonder if s there's a way to have dotnet watch run only recompile backend code? I figure I'd have to run webpack in a different process altogether, but I want to keep HMR + server side rendering, so I want to get your insight.
Thank you.
Activity
SteveSandersonMS commentedon Jan 2, 2017
I don't know how fast it is in your setup, but with the built-in templates here (e.g., Angular 2/React/etc), it takes about 2-4 seconds to do the first-time Webpack build, so it doesn't really feel problematic. How slow is it in your Vue setup? Is 2-4 seconds spent in Webpack an unacceptable delay for you after C# code changes, given that you're probably waiting 5-10 seconds for the server-side process to rebuild and restart anyway? Others haven't reported this as a concern.
Not really, I'm afraid.
dotnet watchstops and starts the dotnet process entirely, so any child processes (e.g., the Node instance that is doing server-side prerendering, and the one that does dev middleware) also have to restart.If anyone has suggestions to improve this please let us know. In the meantime I'll close this because I'm not aware of any action we could take on it. Hope that's OK!
SteveSandersonMS commentedon Jan 2, 2017
Actually one further thing: one possiblity is that we could change the webpack dev middleware logic to serve existing files from disk if they are present rather than waiting for newly-built files. This would make startup faster, at the risk of confusing people by serving
.jsfiles that are inconsistent with the.tsfiles you have on disk. Maybe we will enable that at some point if there's enough demand for it, though I'd be reluctant to make that a default any time soon, given how much it could confuse people!rhyek commentedon Jan 2, 2017
Hi. You are right about the times you mention. ~11s for server and ~4s for webpack. Way too long, I'm afraid. I work at a php shop were people are used to making a change and reloading their browser instantly. I want to get them to try asp.net core, but 15s of wait time every time they press ctrl+s just won't fly.
I like your idea about serving pre existing js files. Not sure under the what circumstances they could become out of sync with src files. Aren't they compiled immediatey on save?
In any case, I would love to at least have the option. Right now I've had to separate the Vue dev server by having it run on its own process and not using this tool, but I've lost server side rendering and I'm forced to work with two CLIs.
rhyek commentedon Jan 2, 2017
Also, if there's something that can be done here I'd rather the issue remained open and tagged as discussion, perhaps? You could change the title or open a new issue, maybe?