Run Your Build
If we run the webpack command directly, we need to set up the path to the webpack executable and look up the right command-line options every time we run the build. Instead, we will create an entry in the scripts section of package.json that describes the build command, so we’ll be able to build the project with the correct options by typing only npm build.
Before we create the build command, we need to install a utility called cross-env to set environment variables in a way that works both for Windows and Unix systems:
| | $ npm i --save-dev cross-env |
Once you’ve downloaded cross-env, open package.json, and in the scripts section, create a new entry to run the build. When it installs an executable, npm places the executable in the node_modules/.bin directory and automatically looks in that location if you don’t specify a path in a script. One annoyance is that we need to define our environment twice—once for Babel and once for webpack. The react-app preset applies different transformations depending on the value of the NODE_ENV environment variables. Use cross-env to set the NODE_ENV to ’production’. This makes sure that Babel applies all the production optimizations. The -p activates production mode for webpack, which turns on minification and replaces occurrences of the process.env in the code that webpack builds.
| | "scripts": { |
| | "build": "cross-env NODE_ENV=production webpack -p" |
| | }, |
Minification shortens variable and function names throughout the source, often to single letters. On top of reducing download times, minification also reduces the time the JavaScript engine needs to parse the code. These techniques often yield very large decreases in file size; you might not feel much difference from a high-speed wired connection in an urban area, but as soon as you navigate on a crowded Wi-Fi network on a train, or if you attempt to connect from a rural area, the loading times will differ hugely.
The -p switch also replaces the process.env variable with the ’production’ string whenever process.env appears in the source code. Right now, this doesn’t change anything, as we’re not using process.env in our own code, but it will turn useful when we install React from npm.
Let’s test our build command. Type npm run build in the project’s directory to launch the build.
webpack prints the files it creates along with their sizes. The app-bundle.js file contains the resulting application code.
| | $ npm run build |
| | cross-env NODE_ENV=production webpack -p |
| | |
| | Hash: 8ce725308ddb93d694b7 |
| | Version: webpack 3.5.4 |
| | Time: 3718ms |
| | Asset Size Chunks Chunk Names |
| | app-bundle.js 151 kB 0 [emitted] app |
| | [77] ./src/saveStatus.js 121 bytes {0} [built] |
| | [78] ./src/index.js 346 bytes {0} [built] |
| | [171] ./src/WordCounter.js 3.94 kB {0} [built] |
| | [172] ./src/ProgressBar.js 586 bytes {0} [built] |
| | [173] ./src/Counter.js 489 bytes {0} [built] |
| | [174] ./src/Editor.js 516 bytes {0} [built] |
| | [175] ./src/SaveManager.js 3.38 kB {0} [built] |
| | [176] ./src/SaveButton.js 224 bytes {0} [built] |
| | [177] ./src/AlertBox.js 603 bytes {0} [built] |
| | [178] ./src/countWords.js 104 bytes {0} [built] |
| | [179] ./src/makeFakeRequest.js 377 bytes {0} [built] |
| | + 169 hidden modules |
To test the minimized code, open index.html and replace index.js with app-bundle.js. Since you don’t need the in-browser Babel transform any more, remove the babel.min.js script from index.html and remove the text/babel type attribute.
| | <script src="app-bundle.js"></script> |
Reload the page to check that the application renders as before. If you get a blank page instead, check the webpack output to see if it encountered an error while processing the files.
You’ve configured both webpack and Babel to create an optimized production build, but during development, it’s more convenient to have a faster build and to preserve more verbose error messages, so next we’ll look at a variation on our build commands that offers a better development experience.