1

Background

In a Webpack configuration, you can specify the naming convention for emitted files as in [name]-[hash].js. I use this in combination with the html-webpack-plugin to generate .html.erb partials for use in a Rails app to include correct assets on deployment. Every Webpack build produces a unique fingerprint in filenames, which works great ... except for when you scale your app to multiple servers, where Webpack is part of the build process (a fresh new build for each server). Rails does a similar fingerprinting of precompiled assets.

github.css
** becomes **
github-448c90f2e2f181cd43b943786ee6f.css

Problem

Because the app is scaled to multiple servers behind a load balancer (using Elastic Beanstalk), the builds must be exactly the same on each deploy. As Webpack generates a unique hash per build, we get 404s on page loads, as the generated assets are not in sync.

Question

Has anyone figured out how to get the same hash across multiple builds? Possibly based on the git commit hash? That's what I'm thinking, but lots of searching has yielded no results. Not above building it myself.

Kyle Ramirez
  • 81
  • 1
  • 6

2 Answers2

0

I had the same problem as Kyle: Using Elastic Beanstalk with multiple servers, each server using Webpack generates a different hash.

First, I tried using [contenthash]. I thought this would work because, unlike [hash], it is based on the content of a file. It didn't work. My suspicion is that each server is using a different salt.

I think you could resolve this by specifying the salt with output.hashSalt, however I have not tested this, as I have since eliminated the need to use a hash in the filename.

Medaglia
  • 11
  • 1
-1

The hashes are deterministic and as long as the content of the included files is the same, the hash will be the same as well. This also includes dependencies, so it's important to have the exact same dependencies.

Yarn uses a yarn.lock file to guarantee that the dependencies installed are identical on every install, this makes it very simple to have the exact same build every time on every machine. With npm you can use npm shrinkwrap to lock down the versions of the dependencies, but this is usually quite tedious to manage (one of the reasons Yarn was created and why it uses a lockfile).

You might also want to read Guides - Caching of the offical docs.

Michael Jungo
  • 31,583
  • 3
  • 91
  • 84
  • 1
    Hey there and thanks so much for your input. I'm actually observing something very different. If I run a webpack build command twice in a row, it will produce all new hashes each time. I am currently using a yarn.lock file to manage dependencies. This occurs locally even. Would you by chance happen to know where you learned that webpack is deterministic in its hash creation? – Kyle Ramirez Mar 23 '17 at 06:36
  • The build is deterministic but the hashes are generated from the final result after the loaders/plugins have been applied ([comment in #1155](https://github.com/webpack/webpack/issues/1155#issuecomment-255381269)). You might have a plugin or loader that uses some state that is unrelated to the files (as in [#3508](https://github.com/webpack/webpack/issues/3508)). But running the build twice in a row on the same machine should always produce the same hash. Other related issues [#950](https://github.com/webpack/webpack/issues/950) and [#1479](https://github.com/webpack/webpack/issues/1479). – Michael Jungo Mar 23 '17 at 16:16