An Introduction To Webpack
Part 2: Configuring Webpack for Development and Production Modes
Hello! Welcome to part 2 of this series of posts (if you haven’t read part 1, read it here). Last time I broke down the Webpack module and how to define an entry point for our front end code, provide a path for our bundled files, how to compile our non-JavaScript files into readable JavaScript, and plugin properties for any tasks can’t be handled by. This post will focus more on configuring Webpack for production mode and deploying production bundles. For this article I’m going to assume you understand the basics of Webpack configuration including Webpack loaders and plugins, as well as importing third-party modules using NPM. With that said, let’s jump right in!
Development Vs. Production
Webpack leverages our code in development mode by providing source mapping and live reloading/hot module replacement using a local host server. It is used to define when to transition between local code and third party code (loaders and plugins) when optimizing our code. Plugins and loaders handle anything that Webpack can not already achieve with its native code. For example, any module that requires the use of global variables can be handled by imports-loader, which will inject global variables into a module. Or we can use HtmlWebpackPlugin to generate HTML files to serve with our bundled code. If you wish to see what plugins are available, the Webpack documentation provides a list of available plugins.
With creating a production build we aim to fulfill the task of minifying our bundles, lightening source maps, and optimization of assets such as image files. Webpack leverages this process by ensuring compilation occurs smoothly and that our code has no errors. Since configuration for Webpack differs between development and production modes in only a few aspects, it’s a good practice to separate differing configurations into their own file. This way we avoid being repetitive with our code. The example below demonstrates an implementation of three files, webpack.config.js, webpack.config.development.js, and webpack.config.production.js. As their namesakes suggest, the latter two files construct dependency graphs in relation to development and production modes, respectively, while the former will contain any common configuration requirements.
The development and production mode configurations each use some of the loaders and plugins exclusively, hence the separation of the Webpack module into three separate modules. The first module webpack.config.js will handle defining entry points and an output path as well as any loaders and plugins used in common when configuring for both development and production modes.
The second module webpack.config.development.js will handle creation of a source map that will define the source location of the various chunks in a bundle file that are made from more than one source file. For example, if bundle.a.js is the output of compiling module.a.js, module.b.js, and module.c.js into one file, then our source map needs to be able to indicate which chunks in bundle.a.js are sourced from module.a.js, module.b.js, or module.c.js. The development and production configuration modules also import webpack-merge, which allows us to use the configuration settings from the common Webpack module using the built-in merge() in each environment mode.
The third module will handle our configuration for production mode. As mentioned for the first two modules, webpack.config.production.js will only define loaders and plugins that it will exclusively use, as well as merge the common configuration from the first module.
That’s all for today! Thank you for reading this second part of my series of posts about the fundamentals of Webpack! Until next time!
Sources Cited
“Configuration | Webpack.” Webpack, https://webpack.js.org/configuration/. Accessed 21 July 2021.
Owens, Tom. Webpack 5 Up and Running. 1st ed., Packt Publishing, 2020, pp. 80–94, 118–24.
