Specifying host and port for the hot module reload server?

[jbellmore]

Is it possible to specify the host and port used by the dev server that hosts the hot module reload? From what I am seeing the HMR server is hosted on a random port at startup and 302 redirects are used by the middleware to tell the application where to find the actual files produced by the web pack hot reloading.

This is difficult in a situation like running inside of docker containers as it is impossible to know which port should be forwarded when using docker/docker compose so the 302 redirects will always fail.

From what I can tell the only way to specify the host and port for the web pack dev server is through the cli arguments and does not appear to be able to be set in the config file unfortunately.

I would propose the host and port be added to the WebPackDevMiddlewareOptions so that they can be then passed in when the node process hosting the dev server is started.

Unless I am missing something and there already is this capability?

Thanks!

[SteveSandersonMS]

Great point. Yes, you're right: the webpack dev middleware does use a 302 to pass the client's request through to the internal webpack service.

I've added a new option, HotModuleReplacementServerPort, which you can use as in this example:

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

Remember to specify a high-numbered port (e.g., in the range 1025-65535). This config option is optional - if you don't specify HotModuleReplacementServerPort, then Node will pick its own high-numbered port for the internal service.

Usage

To get this new facility, you'll need to:

1. Update to the latest version of the aspnet-webpack NPM package (currently, that's 1.0.9)
2. Update to the latest version of the NodeServices/SpaServices/etc NuGet packages (currently, they're all 1.0.0-beta-000009)

... then you can specify HotModuleReplacementServerPort on your WebpackDevMiddlewareOptions, and can pass through traffic to this port when launching Docker, e.g.,

docker run -p 5000:5000 -p 50505:50505 --env ASPNETCORE_ENVIRONMENT=Development <yourimage>

... and it will connect to the HMR endpoint.

I would propose the host and port

I've also updated SpaServices so that, in the 302, it preserves the client's view of the hostname it's connecting to (i.e., it's not hardcoded to localhost any more - it will pass through whatever IP address or hostname you originally requested). I'm hoping that will be sufficient. Please let me know if there's an important use case for configuring the hostname (obviously, we try to minimise the amount of config options that people can get tangled up in).

---

Note for future reference: this whole thing of using a 302 to the internal webpack service, rather than proxying the request directly, is just a workaround for a limitation in some ASP.NET Proxy middleware code that's not compatible with long-polling. We already proxy requests for the actual client-side webpack resources (e.g., files under wwwroot/dist); we only use 302s for the /__webpack_hmr requests because they need to support long-polling. In the future, we might change WebpackDevMiddleware so that it does complete proxying for all webpack requests including /__webpack_hmr. At that point, the client would never directly contact the internal webpack service, so there would no longer be any need to configure the port number, and so we would be able to remove this config option.

[jbellmore]

Wow, you work fast, thanks so much!

This is perfect I will be updating and testing it out shortly. As for the hostname the only situation I could possibly think of would be if you wanted to run the webpack server on a different vm or container but honestly can't imagine why anyone would want to do that. I think the solution you implemented works for the most likely situation which would be running the Docker container inside of a Vagrant box so it would not be running on localhost but rather the IP.

Thanks again, loving this project keep up the good work!

[jbellmore]

The fix works great, hot module loading is working inside Docker container perfectly!

Thanks again!