Tree Shaking simplified with Webpack!

Writing a simple, clean, and efficient code is the most desirable quality that every developer seeks. Most of the time, there is an unused code that floats around when you import and export modules in JavaScript. The concept of tree shaking, or dead code elimination plays a great role as it avoids a largely created bundle size unused module that hampers the performance during the build procedure. Tree shaking is seen as one of the best practices followed by front-end developers that focuses on the size and performance factors. Not limited to front-end, tree shaking can be followed as a go-to practice by all. Let’s see what the exact idea behind tree shaking is.

Principles behind Tree Shaking:

  • Declare all your imports and exports for each of your modules.
  • The bundler (Webpack, Rollup, etc.) will analyze the dependency tree during your compilation step.
  • Any unused code that can be proved is automatically dropped from your final bundle or tree shaken.

To carry out the tree shaking do not forget to use the ES6 style for importing and exporting. Also, disable the transformation of ES modules syntax to another module type. Just set the value to false as it will preserve the ES modules.

“amd” | “umd” | “systemjs” | “commonjs” | “cjs” | “auto” | false, defaults to “auto”

You can use Babel, which is a free and open-source JavaScript transcompiler, to transpile code. All your import and export statements are by default transpiled down to CommonJS. This forces the webpack to de-optimize and some trees may be left unshaken.

Tree Shaking with Webpack

Webpack supports tree-shaking and it uses babel-preset-env package. This package bundles the files and transforms them back to CommonJS modules. This makes it difficult to bundle using tree-shaking. To achieve tree-shaking while bundling the application, you will need some configurations that will enable tree-shaking with webpack. Let’s have a look at them -

// webpack.config.js 
const HtmlWebPackPlugin = require('html-webpack-plugin');
module.exports = {
  module: {
    rules: [
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: babel-loader,
          /* This configuration aids babel-preset-env to disable transpiling of import or export modules to commonJS */
          options: {
            presets: [
              [ 'es2015', { modules: false }]
  plugin: [ new HtmlWebPackPlugin ({ 
    template: './src/index.html',
    fileName: './index.html'

That’s pretty simple, isn’t it? However, before you go on to shake trees with webpack, there is another important concept that you should consider and that is configuring the side effect. It is only visible when a function or expression modifies a state outside its context. The common examples of side effects include making a call to API, manipulating the DOM, or writing to a DB.

So, to make webpack aware of the state of the files it’ll transpile, you should configure a change in either package.json file or within the webpack.cofig.json. Here is how you can do that…read more