Webpack中实现更优Tree Shaking的正确方式？两种导入方式选哪个？

Great question! Tree shaking is one of those optimizations that can make a huge difference in bundle size when done right, so let's break this down clearly.

To get the most out of tree shaking in Webpack, follow these key steps:

• Stick to ES module syntax: Tree shaking relies on Webpack's ability to statically analyze imports/exports. Avoid using CommonJS require() calls, as they're dynamic and can't be reliably tree-shaken. Make sure your code and dependencies use import/export syntax.
• Enable production mode: Webpack's production mode automatically enables critical optimizations like optimization.usedExports (which marks unused code) and minification (which removes that code). Just set mode: 'production' in your Webpack config.
• Declare side effects correctly: Add a "sideEffects": false entry to your project's package.json if your code has no unintended side effects (like modifying global variables on import). If some files do have side effects, list them explicitly: "sideEffects": ["./src/polyfills.js", "*.css"]. This tells Webpack it can safely remove unused exports from side-effect-free modules.
• Configure Babel properly: If you're using Babel, ensure @babel/preset-env has modules: false set. This prevents Babel from converting ES modules to CommonJS, which would break tree shaking. Your Babel config might look like this:

  {
    "presets": [
      ["@babel/preset-env", { "modules": false }]
    ]
  }
  

• Avoid importing entire modules: Instead of importing an entire library (e.g., import _ from 'lodash'), only import the parts you need. This reduces the amount of code Webpack has to process and shake out.
• Use optimized dependency versions: Choose dependencies that are published as ES modules (like lodash-es instead of the standard lodash). CommonJS modules can't be fully tree-shaken, so ES module versions will give you better results.

Let's compare your two options:

Option 1: import { someFeature } from 'someModule' #

This works great if someModule is an ES module with proper side effect declarations. Webpack can statically analyze the imports, identify that only someFeature is used, and shake out the rest of the module's unused code. For example, using import { isEmpty } from 'lodash-es' (the ES module version of Lodash) will let Webpack tree shake the unused Lodash functions.

Option 2: import someFeature from 'someModule/someFeature' #

This approach directly imports a single file/feature, which guarantees you're only pulling in the code you need. This is especially useful when:

• The module is written in CommonJS (like the standard lodash package). Since CommonJS can't be statically analyzed, import { isEmpty } from 'lodash' would actually import the entire Lodash library, whereas import isEmpty from 'lodash/isEmpty' only imports the specific isEmpty function.
• The module doesn't have proper sideEffects configuration. Even if it's an ES module, if Webpack can't confirm it's side-effect-free, it might not shake out unused code—direct imports avoid this issue.

Final Verdict #

If your target dependency is an ES module with correct sideEffects setup, Option 1 is cleaner and works just as well for tree shaking. If the dependency is CommonJS or lacks proper configuration, Option 2 is the safer choice to ensure minimal bundle size. For Lodash specifically, use lodash-es with Option 1, or stick to Option 2 with the standard lodash package.

内容的提问来源于stack exchange，提问作者UtkarshPramodGupta