How We Upgraded to Webpack 5

Webpack 5 was officially released on October 10, 2020, and we tried to implement the upgrade in the same week. However, it did not work.

Finally, on August 13, 2021, after several more attempts, we merged the upgrade to production, only to end up reverting back the same day.

Apart from the speed that came with the newest version, we wanted to be up to date. Developers (especially the younger ones) are very reluctant to use older versions of any library, even if they work better than the new ones. :)

Our Webpack config is not long or complicated, but it is not a classic config for a single-page application. The output of our build was "library", which was enough to make this not an easy upgrade.

Don't rush, but don't wait too long

The rule is not to rush anything. I do not have this mathematically calculated but every month you wait for an update, your chance of succeeding doubles.

The Webpack ecosystem is big and when a new version comes out, a lot of plugin developers need time to do their part of work. You wait for the really eager ones to find the early bugs and to write the first Stack Overflow questions and blog posts, which you can later use to accomplish a smooth upgrade.

On the other hand, you cannot wait too long. We are talking JavaScript here, and you never know when the next major version will be released.

RTFM

The second rule is to read the migration manuals.

When we finally got our local server and build working, we ran into a big problem. The new version was significantly slower than the previous one. And there were similar stories on the internet. We didn’t know if it was because of Webpack 5 or because we did something wrong.

It took our local server about 120 seconds to start on the Webpack 4. On the Webpack 5, it took about 200 seconds. So, we waited for another month, with no success.

Going through the migration manual again, I found that  static.watch in webpack-dev-server is enabled by default. Bang! That was it. When we turned that setting off, our local server started in about 80 seconds. We were close.

{
  devServer: {
    host: '0.0.0.0',
    port: 3000,
    static: { watch: false },
    historyApiFallback: { disableDotRule: true }
  }
}

Why did static.watch have such a significant impact on our local development?

The watch option was set to check the whole project, all of the source codes, even the whole node_modules folder. We had the root of our project as a root directory for our local server. This wasn't an issue with Webpack 4.

There were two solutions available to us: turn off static.watch or make a regular public directory. We did both. The watch option has no significant impact if you have a regular public directory that contains only your app assets. However, if you do not touch your files there, I suggest turning the watch setting off.

Summary

The upgrade took a little bit longer than we had expected. The results were good—our local server started about 33% faster. The build took about the same time as on the older version. The Webpack team is working hard on developing better and quicker versions, and we are happy to take advantage of the gain in speed.