Configure Webpack for Production Build — Part I
What are the differences between production build and development build?
Development build aims to optimise the experience of devs who actively modifying the source code; thus have features such as source mapping, live reloading, hot module replacement.
On the other hand, Production build aims to optimise the experience of the users; and therefore enabling users have access to most updated version of the website/app in short loading time becomes the main focus.
Development
A simple version of webpack.config.js to enable development may look like:
It basically takes the source code from the ./src folder and transpile them into main.js in the ./dist folder. The index.html then loads ./dist/main.js in the script tag. A simple, quick webpack set up for development.
For production build, we want
- Users browsers automatically updates the cache when an updated main.js is published (Auto-versioning)
- Fast loading time for our app (Minification, tree shaking, bundle split, code split…)
Auto-versioning
Automatic cache update can be achieved via auto-versioning using dynamic name generation.
Browsers do caching to reduce the load time. If a resource has been loaded to the browser, it will be cached so that the browser will not fetch it again from the server. However, it may cause headaches when there is new change to the file that we want the browser to pickup. e.g. there is an update to the website, but the resources cached in the browser still have the same name. The users won’t be able to experience the latest change.
In development, we can enable live-reload to always fetch the latest JS files, but in production, users have to do a hard refresh.
To force the browser to automatically update the cache when a new version of the assets comes out, we can auto-version our assets. One way to do this is to add a build-specific hash in the filename. e.g. main.[chunkhash].js (Webpack produces a hash when it runs, which we can see from the terminal screen) By using HtmlWebpackPlugin, we can dynamically create a new index.html file which loads the newly generated main.[chunkhash].js. Since the index.html created doesn’t have the <div id=“app”></div> element for React to mount the other components on, we can create that by using a template. Also, it is best to use CleanWebpackPlugin which cleans files given in the path and is useful when bundled files are generated with new names dynamically.
Note that in module.export.output, the publicPath is the public URL address of the output files. It is not where the files are located as opposed to path. If all our assets are in the /dist folder and we use an express server, we can route the requests for the /assets to the /dist folder by app.use(‘/static’, express.static(‘public’)).
References:
With the Auto-Version webpack.config.js, we can expect a new hash produced when webpack finds a new change in the file, else the hash stays the same.
However, after we add chunk-hash to the filename, we may find that the name still gets a new hash even though there is no change to the files. It is because the manifest boilerplates produced by webpack gets changed when webpack runs and thus getting a new hash.
To get around that, we can split out manifest into a separate file. That way our own code, main.js, will not get a new hash as long as there is no change in our code. (See bundle splitting in the Next Post)
Referrences:
https://survivejs.com/webpack/optimizing/adding-hashes-to-filenames/
https://webpack.js.org/plugins/html-webpack-plugin/
Note: The examples are based on Webpack 3. Please note there are a few difference between Webpack 3 and 4. The concepts are the same, but do look up the latest Webpack 4 documentation for the right syntax if using Webpack 4.