webpack v1 from Kent
Tree shaking with Webpack 2
The less code you can send to the browser, the better. The concept of tree shaking basically says that if you’re not using some piece of code, then exclude it from the final bundle, even when that piece of code is exported from a module. Because ES6 modules are statically analyzable, Webpack can determine which of your dependencies are used and which are not. In this lesson, see how to take advantage of this awesome feature in Webpack 2.
[00:00] One of the aspects of ES6 modules is that they're statically analyzable. This means tools like Webpack can predict exactly which exports are used and which are not. Webpack takes advantage of this with a feature called "treeshaking." This feature can seriously reduce bundle sizes in large applications.
[00:15] Let's take a look at our helpers file here, we have this function addClass down here below. The only place the function is being used is in the app.js file, meaning that if we removed it from the app.js file, it's no longer needed in our bundle.
[00:28] Let's go ahead and do that, and now, we can open up our app, everything is still working. But if we look in thehelpers.js file, we see the addClass function is still being exported.
[00:39] That's to be expected, because we're still exporting this from the helpers file, and Bable is transpiling our ES6 module exports into common JS exports. Because this is getting transpiled down to common JS, it's not statically analyzable like ES6 modules, and so, Webpack can't reliably treeshake this function, and our bundle will include it even though it's not in use.
[01:02] We're going to use a different Bable preset, which excludes the transpilation of ES6 modules and leave that to Webpack.
[01:08] Now, let's install Bable Preset ES2015 Webpack, and now, if we open up our bable.rc file, we'll trade out the ES2015 with ES2015 Webpack preset, and then, just for the sake of completeness, we'll go ahead and get into our package.JSON and remove the original preset, because the Webpack version of this preset will have all of the other transforms that we need. We'll save that, and now, we'll run npm start to start up our application.
[01:38] This will automatically refresh, and now, we'll see that the helpers file is a little bit different with regards to how these ES6 module exports are transpiled. Before it was pretty straightforward common JS. Now, it's a little bit different because Webpack is going the transpilation for us.
[01:55] Because Webpack has an understanding of all the modules throughout our system, it realizes addClass is not being used anywhere in our application, and so, it adds this comment, "Unused harmony export addClass," and it excludes it from the list of things that are being added to our common JS export.
[02:13] You'll notice though, that the addClass function is still being added in here, but because it's not being referenced, when we go ahead and uglify our code using the uglify.js plug-in, this function will be automatically removed.
[02:25] We can verify that by running our production build. To do this, we can run NPM run build prod, which as you can see, is running node emv production Webpack with the -e flag, and if we scroll up here, we'll see this warning from uglify.js, "Dropping unused function addClass."
[02:42] Because that addClass function is not being referenced in any of the code inside of the helpers file, it's being dropped from our bundle, and we're not shipping that unused function to browsers.
[02:52] This applies to more than just our application code, this would apply to any ES6 module that we're importing into our application, including third-party dependencies.
[03:01] In review, all we had to do to leverage treeshaking with Webpack 2, is to install Bable preset ES2015 Webpack so that Bable doesn't transpile our ES6 modules, and then, we update our Bable.rc file to use that preset instead of the Bable preset ES2015 module. That's how you leverage treeshaking with Webpack 2.