The Problem: Using webpack-dev-server’s livereloading and HMR features on a remote machine (probably over nginx)

The Solution is further down on this page for the impatient (or those who very reasonably don’t care to read about how I got into this situation and how long it took me to solve it!).

The Fluffy Backstory

The joys of livereloading, hot module replacement, instant style updates and their related, rapid relatives have only recently come into focus for me. Now that I’ve seen this dazzling light the idea of toiling away in a dark alley of constantly Ctrl-Ring a browser window makes me very miserable. I’ve recently adopted a workflow that involves working on a remote, hosted VPS over SSH in the terminal. I love almost all the things about it, but it briefly pushed me down the dark Ctrl-R alley. The main reason is simple: You’re no longer hitting a localhost:NNNN page anymore - instead you’re going out over the internet.

There are a few issues:

• On-Disk vs In-Memory builds of the site
• Hosts and DNS
• Ports (who uses which ports, who knows this, how to tell the various parties what’s where)
• Firewalls
• Things about HTML headers
• Things about websockets

I spent hours and hours and purpled all google searches I could think of. sometimes after spiraling around I’d come back around to older google search results but this time I’d have a different set of configuration combinations as a result of walking through previous google search results so I’d try some of these things mixed in with weird combinations of other stuff I’d already tried.
It was one big shitty salad of port, host, webserver combinations.

By the end, the viable solution is, in summary, this:

• A publicly-accessible URL (let’s call it http://devenv.com. and I already checked, it’s taken) with DNS records pointing this domain to the IP of the VPS we’re working off of.
• A static-built version of the files at /dist, served up by a simple nginx server block pointed to the static index.html when navigating to http://devenv.com.
• webpack-dev-server running, serving an in-memory version of the site over local port 8080.
  • another nginx server block using a subdomain such as http://live-and-hmr.devenv.com which proxies the websocket connection over to the above webpack-dev-server process on 8080.

What I didn’t understand originally was that webpack-dev-server is a server (duh) and as a result nginx should not be doing the serving of that resource. It merely needs to step aside and hand off the responsibility to webpack-dev-server. This tripped me up, conceptually, before it clicked and prevented me from reasoning properly enough about the solution in order to arrive at it earlier.

One wouldn’t have to use the two URLs (with and without the subdomain going to the static and dev-server versions) but I found it convenient to be able to work off the HMR dev-server version 90% of the time while keeping the convenience of building the site and flipping over to the static tab for a sort of more productiony experience.

I thought a bit about why there were so few Stack Overflow posts or blog article about this solution and I arrived at: The remote dev vps approach is relatively uncommon and it may be even less common among front end developers. This is a bit of an assumption and maybe a rude-ish one, but one which is grounded by this bias: Front-end-mostly devs are more likely to be spending their valuable time working on javascript/webpack/gulp/styling workflows, etc. - all of which are noble pursuits and beautiful, but its easy to spend much of your time in that world without having to worry about hosting details, nginx, processes/ports, and the like.
To be clear, this is not a value judgement. Quite the contrary; being a mostly-back-end-developer myself I started off with very little knowledge on the front end challenges listed above and I have a lot of respect for those who know this stuff inside and out.
It has been a long and rewarding journey for me.

The Solution

Enough of my yakking! When I finally got the thing working I hastily noted it all down in a GitHub Gist (after doing a lot of wild, expletive-laced celebratory gesturing). The Gist will likely make enough sense to someone well-versed in webpack and its configuring, but I don’t know that its the clearest thing. Let me know if you have questions.

• Link to gist
• Embed:

# webpack.config.js

module.exports = {
  entry: {
    app: './src/index.js',
  },
  devtool: 'inline-source-map',
  plugins: [
    new CleanWebpackPlugin(['dist']),
    new HtmlWebpackPlugin({
      title: 'Output Management',
      filename: path.resolve(__dirname, 'dist/index.html'),
      template: path.resolve(__dirname, 'src/index.html'),
    }),
    new webpack.NamedModulesPlugin(),
    new webpack.HotModuleReplacementPlugin()
  ],
  devServer: {
    # !! here are the important parts !!
    disableHostCheck: true,
    host: '0.0.0.0',
    port: '8080',
    hot: true
  },
  output: {
    filename: 'js/[name].bundle.js',
    path: path.resolve(__dirname, 'dist'),
  }
};

# nginx conf file

upstream some_arbitrary_name_here {
  server 127.0.0.1:8080;
}

server {
  listen 80;

  # use your built /dist folder location here:
  root /some/root/maybe/www/dist;

  index index.html;

  server_name dev.YOUR-DOMAIN.com;

  location / {
    try_files $uri $uri/ =404;
  }
}

server {
  listen 80;

  # notice the different subdomain here:
  server_name live-dev.YOUR-DOMAIN.com;

  location / {
    proxy_pass http://some_arbitrary_name_here/;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Bonus for Rails + Webpacker users

There’s another post forthcoming on Rails + Webpacker over VPS, but for now here’s another hastily-written gist with the solution for that setup (warning: it’s weirder):

• Link to gist

(cross-posted to dev.to)

Questions, comments, concerns and ridicule all welcome below!