Webpack Dev Middleware not working (HMR and React HMR)

[jzbyers]

This issue is very similar to closed issue #422, which unfortunately was unable to solve my problem. In #422, the fix was to update Node, but I already have a stable version of Node more recent than the one listed in #422.

My environment

macOS Sierra v10.12.5
VS Code v1.14.1
Node.js v6.10.0
.NET Core SDK, which contains .NET Core 1.0 and 1.1

Steps to reproduce (some steps copied from the README):

Install Yeoman and these generator templates:

npm install -g yo generator-aspnetcore-spa

Generate your new application starting point:

cd some-empty-directory
yo aspnetcore-spa

This command should fail during the build process, which you can fix by following issues #1120 and #1099. I also referenced these issues in #1132. In summary, you'll probably need to install more recent versions of some npm packages, including typescript and some @types/.

Make sure that your Startup.cs file contains a block of code similar to the following, to make sure HMR will be in place during development mode:

app.UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions {
    HotModuleReplacement = true,
    ReactHotModuleReplacement = true
});

Once the generator has run successfully (and if it hasn't, once you've successfully installed stable dependencies), you can start up the app. Before running, though, make sure you're running the app in development mode so that the app will use webpack dev middleware. Start up the app with:

dotnet run

Open a browser (I've been using Chrome) and navigate to the correct localhost port. Open a file in the ClientApp directory, like components/Home.tsx and change something simple. When you save the file, in your terminal you should see something like:

info: Microsoft.AspNetCore.NodeServices[0]
      Node will restart because file changed: /Users/your-username/code/aspnetcore-reactredux/ClientApp/components/Home.tsx

Flip back to the browser and reload the page. For me, the change does not appear, and I don't think Node ever rebuilt the ClientApp code using webpack.

The only way I can get the change to take place is if I run webpack manually from the terminal.

Any thoughts?

[SteveSandersonMS]

Could you try this with the latest .NET Core 2.0 Preview 3 templates? These will be shipping as finished products very soon, so all ongoing work will be happening there rather than in the old Yeoman templates.

• Install a current preview 3 SDK from the 2.0.0 branch
• In an empty directory, run dotnet new redux (or angular, or react). Note that Yeoman is not involved.
• Run npm install
• Be sure to set an env variable for ASPNETCORE_Environment with value Development
• Run dotnet run. Verify it says Hosting environment: Development, to confirm you did set the ASPNETCORE_Environment env var correctly.
• In your browser console, verify you see [HMR connected]
• Now edit a source file.

With this setup, you don't need to manually change any NPM packages as all the dependencies are already correct.

I've verified this works, but please let me know if you hit any issues.

[jzbyers]

Thanks! Do you by chance have root access?

I think I can get around this second issue by following #7119 at dotnet/cli, but for everyone else's sake, on first try I'm having some permissions issues that you all might run into as well:

Following the steps from Steve above, when I run dotnet run I get the following error:

System.UnauthorizedAccessException: Access to the path '/Users/your-username/.dotnet/2.0.0-preview3-006885.dotnetFirstUseSentinel' is denied. ---> System.IO.IOException: Permission denied

I'm having this problem with both the pkg installer and the tar.gz. I can sudo to get through all the permission denials, but once I create a new project, I can't edit any of the files because they've been created with root access.

See #7119 at dotnet/cli for more info. The fix appears to be in 2.0.0-preview3-6736.

[stephenlautier]

We are having the same issue for angular template, however for our existing project. When creating a new template, as @SteveSandersonMS suggests, it works fine.
I'm trying to sync as much as possible, however still no luck.

• Its running as Development
• [HMR connected] is not being triggered
• No warnings/errors are logged
• HMR scripts are missing

// output
if (false) {
    module.hot.accept();

Is there anything I can check? In order to understand why the HMR scripts are not there.
Thanks!

[stephenlautier]

After some hours of debugging I managed to find something, basically we had:

JsonConvert.DefaultSettings = () => new JsonSerializerSettings
{
	Formatting = Formatting.Indented,
	ContractResolver = new CamelCasePropertyNamesContractResolver()
};

Which caused to change properties for the webpack server when it initializes, and ts code is expecting them to be PascalCased rather than camelcas'ed. Perhaps I can open an issue there and improve that a bit

[remware]

Any update in this issue?

[SteveSandersonMS]

It sounds like both @jzb3db and @stephenlautier have described their resolutions. @remware, if you have an issue, could you please post a new issue with repro steps for your specific case?

[remware]

Hi, I could not get above resolution, it was not clear what code needs to be patched or what updated version to use. As per steps to reproduce I have basic VS2017 Update 15.3.1, dotnet core 1.1.2 ( 2.0 installed but not targetted ), Node v6.11.0, webpack 2.5.1, aspnet-webpack 1.0.29, webpack-hot-middleware 2.18.0. The way I get over the issue was to install webpack globally and then execute deployment in VS2017 webdeploy. Not sure how to reproduce it.

[jzbyers]

Hi @remware, while I did find a workaround by promoting my permissions, there might still be an issue with the package installer. Ideally, nobody would have to mess with their own permissions to get this to work. To that point, @livarcocc shed light on the root cause of the issue we're having in #7119 at dotnet/cli, and suggests we try again with a more recent build.

He explains that in the pkg installer, dotnet new was being called by the root user, which would cause file permission problems if you haven't given yourself root privilege. He goes on to say that in the latest builds, this issue should be fixed.

I have not yet had the chance to test these new builds out, but as soon as I find the time I'll give it a shot and report back.