Webpack tree-shaking with Babel
In this post we are going to cover a couple different things:
- What is tree-shaking?
- How to use tree-shaking?
- How does webpack handle tree-shaking?
What is tree-shaking?
Tree-shaking is the process of analyzing your code and only including the parts you explicitly import for your application to run.
Okay, what is dead code elimination? Good question.
Dead code elimination approaches the problem from the opposite end. It analyzes your code after its been bundled and removes the code that is not being used in your application.
Ultimately they both are being used to remove unnecessary code.
That being said, here is a one liner to help explain it to all your friends.
Rather than excluding dead code, we’re including live code. (Tree-shaking)
-Rich Harris creator of RollUp
For more information on the differences between these two I recommend checking out this medium article by Rich. He does a much better job than I do explaining the differences between these approaches.
How to use tree-shaking?
Thanks to ES6 imports and exports we can explicitly say what pieces of code we want to import into our application.
Setup
The following code requires that you have webpack 2 installed plus babel-loader and babel-preset-es2015.
webpack 2
$ npm install webpack --save-dev
babel-loader & babel-preset-es2015
$ npm install babel-loader babel-core babel-preset-es2015 --save-dev
To use local version of webpack you need to add two scripts to your package.json. One for for dev(start) and one for prod(build). The -p flag in the build script tells webpack to run UglifyJs plus other production considerations when bundling. For more info, check out the building for production guide on webpack.js.org.
package.json
Next we need to setup our webpack config. Should look something like this.
webpack.config.js
The most important part in this is the option that we pass to the es2015 preset of { "modules": false }. This tells babel not to compile our ES6 modules to CommonJs modules.
We don’t want babel to compile them to CommonJs because webpack 2 understand ES6 imports/exports which is what allows it to do tree-shaking.
Now with our basic setup in place lets take a look at some code.
index.js
Here we are stating that we would only like to import foo from our utils file and then we are calling foo.
utils.js
Above we have a simple utils file where we are exporting two functions. Clearly we can see that we are not using the bar function. Let’s see what happens when we run our build.
$ npm start
This will generate a file called index.bundle.js in your /build directory. If you open that up and scroll to what looks like your code you will notice the bar function is still there.
index.bundle.js
Whats important to note here is this bit.
/* unused harmony export bar */.
This basically tells UglifyJs that it can remove bar() from the code when it runs its check for dead code.
Now run the build script to optimize with UglifyJs.
$ npm run build
You should see less code now in your index.bundle.js.
index.bundle.js
How does webpack handle tree-shaking?
We already discussed this briefly above but its worth repeating.
In webpack 2 it understands ES6 imports/exports without the need for babel to compile those to CommonJs. Since webpack has this capability now, that means it understand which functions are used and which ones are not. So as webpack is bundling your code it marks pieces of code that it knows are not being used with certain flags. Such as this.
These flags are then picked up by UglifyJs and its dead code elimination algorithm that results in a bundle that has been minified and removed of any excess code.
It seems that some consider this approach to be an issue. If you have strong feelings about how this should be handled then head on over there and voice your opinion.
Links
If you liked this article then please show some ❤️ below. If you didn’t then lets talk about it below 😃.
Originally posted on my blog at http://johnstewart.io.
