Jonathan.Brink
Jonathan.Brink

Reputation: 25423

Why webpack doesn't tree-shake the lodash when using "import * as _"?

I am learning about tree-shaking with a webpack 4/React application that uses Lodash.

At first, my Lodash usage looked like this:

import * as _ from "lodash";
_.random(...

I soon learned, via the BundleAnalyzerPlugin, that the entirety of Lodash was being included in both dev and prod builds (527MB).

After googling around I realized that I needed to use a specific syntax:

import random from "lodash/random";
random(...

Now, only random and it's dependencies are correctly included in the bundle, but I'm still a little confused.

If I need to explicitly specify functions in my import statement, then what role is the tree-shaking actually playing? The BundleAnalyzerPlugin isn't showing a difference in payload size when comparing between dev and production mode builds (it's the correct small size in both, but I thought that tree-shaking only took place with production builds?).

I was under the impression that TreeShaking would perform some sort of static code analysis to determine which parts of the code were actually being used (perhaps based on function?) and clip off the unused bits.

Why can't we always just use * in our import and rely on TreeShaking to figure out what to actually include in the bundle?

In case it helps, here is my webpack.config.js:

const path = require("path");
const BundleAnalyzerPlugin = require("webpack-bundle-analyzer").BundleAnalyzerPlugin;

module.exports = {
  entry: {
    app: ["babel-polyfill", "./src/index.js"]
  },
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: "static",
      openAnalyzer: false
    })
  ],
  devtool: "source-map",
  output: {
    filename: "[name].js",
    path: path.resolve(__dirname, "dist"),
    chunkFilename: "[name].bundle.js",
    publicPath: ""
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: "babel-loader",
        include: /src/,
        options: {
          babelrc: false,
          presets: [
            [
              "env",
              {
                targets: {
                  browsers: ["last 2 Chrome versions"]
                }
              }
            ],
            "@babel/preset-env",
            "@babel/preset-react"
          ],
          plugins: ["syntax-dynamic-import"]
        }
      },
      {
        test: /\.(ts|tsx)$/,
        use: [
          {
            loader: require.resolve("ts-loader"),
            options: {
              compiler: require.resolve("typescript")
            }
          }
        ]
      }
    ]
  },
  resolve: {
    symlinks: false,
    extensions: [".js", ".ts", ".tsx"],
    alias: {
      react: path.resolve("./node_modules/react")
    }
  }
};

I'm invoking webpack with webpack --mode=development and webpack --mode=production.

Upvotes: 26

Views: 33739

Answers (3)

AmerllicA
AmerllicA

Reputation: 32572

Actually, it is not related to the Webpack ability to tree-shake. base on Webpack docs about tree-shaking

The new webpack 4 release expands on this capability with a way to provide hints to the compiler via the "sideEffects" package.json property to denote which files in your project are "pure" and therefore safe to prune if unused

When you set the "sideEffects: false on your package.json based on the linked docs:

All the code noted above does not contain side effects, so we can simply mark the property as false to inform webpack that it can safely prune unused exports.

If you have some files or packages which you know they are pure add them to sideEffects to prune it if unused. There are some other solutions to do tree-shaking that I proffer to read the whole article on Webpack docs.

One of the manual ways are using direct importing like below:

import get from 'lodash/get';

That Webpack understands add just get from the whole lodash package. another way is destructing importing that needs some Webpack optimization for to tree-shaking, so you should import like below:

import { get } from 'lodash';

Also, another tricky way is just to install a specific package, I mean:

yarn add lodash.get

OR

npm install --save lodash.get

Then for import just write:

import get from 'lodash.get';

Definitely, it is not tree-shaking, it is a tight mindset development, but it causes you just add what you want.

BUT

YOU DON'T DO ANYTHING OF ABOVE SOLUTIONS, you just add the whole package by writing import * as _ from "lodash"; and then use _.random or any function and expect Webpack understand you wanna the tree-shaking be happening?

Surely, the Webpack works well. you should use some configs and coding style to see the tree-shaking happens.

Upvotes: 6

zeptonaut
zeptonaut

Reputation: 905

If you're already using Babel, the easiest method to properly tree shake lodash is to use the official babel-plugin-lodash by the lodash team.

This uses Babel to rewrite your lodash imports into a more tree-shakeable form. Doing this dropped my team's bundle size by ~32kB (compressed) with less than 5 minutes of effort.

Upvotes: 3

Austaras
Austaras

Reputation: 951

All two existing answers are wrong, webpack do treeshake import *, however that only happens when you're using a esmodule, while lodash is not. The correct solution is to use lodash-es

Edit: this answer only applies to webpack4, while webpack 5 supported a limited subset of tree shaking for commonjs, but I haven't tested it myself

Upvotes: 30

Related Questions