基于Webpack构建PNPM Monorepo：产物体积过大问题排查

一、先排查可能的操作失误 #

• 共享工具包模块格式与Tree Shaking支持不足
  • 未在package.json中设置"type": "module"，或未通过exports字段明确ESM/CJS入口，导致Webpack无法识别可摇树的模块结构。
  • 未配置sideEffects字段：如果共享工具包无副作用代码，未设置"sideEffects": false，Webpack会默认保留所有文件，无法安全摇树；如果有副作用文件（如全局样式），未明确列出路径。
  • 共享工具包构建输出为CJS格式：比如用Webpack打包成UMD/CJS，而非ESM，Tree Shaking仅对ESM模块生效。
• Webpack配置未正确开启Tree Shaking
  • 未设置mode: 'production'：production模式默认开启Tree Shaking，development模式下会禁用。
  • 未配置optimization.usedExports: true：该选项会标记未使用的导出，配合Terser完成代码删除。
  • Babel破坏ESM结构：使用@babel/preset-env时未设置modules: false或modules: 'auto'，导致ESM被转译为CJS，失去摇树能力。
• PNPM依赖处理问题
  • 共享工具包的依赖被重复打包：比如共享工具包将bignumber.js设为dependencies，子项目又单独安装，导致重复打包；或PNPM的hoisting策略导致无关依赖被引入。
  • 子项目未正确引用共享工具包：未使用workspace:*协议，导致安装的是npm上的包而非本地开发版本，无法参与本地构建优化。

二、正确的PNPM Monorepo搭建规范 #

1. 共享工具包配置 #

• 明确模块格式
  在package.json中配置：

  {
    "type": "module",
    "exports": {
      ".": {
        "import": "./dist/index.esm.js",
        "require": "./dist/index.cjs.js"
      }
    },
    "sideEffects": false, // 无副作用时设为false，有副作用则列出路径如["src/styles/*.css"]
    "main": "./dist/index.cjs.js",
    "module": "./dist/index.esm.js"
  }
  

• 构建工具选择
  使用Rollup或tsup构建，输出ESM格式，保留原始导出结构，避免打包成单文件：
  示例Rollup配置（rollup.config.js）：

  import { nodeResolve } from '@rollup/plugin-node-resolve';
  import typescript from '@rollup/plugin-typescript';
  
  export default {
    input: 'src/index.ts',
    output: [
      { file: 'dist/index.esm.js', format: 'es' },
      { file: 'dist/index.cjs.js', format: 'cjs' }
    ],
    plugins: [nodeResolve(), typescript()],
    external: ['bignumber.js'] // 将第三方依赖设为external，避免打包进共享工具包
  };
  

2. 子项目Webpack配置 #

Serverless Lambda项目

• 开启Tree Shaking

  module.exports = {
    mode: 'production',
    optimization: {
      usedExports: true,
      minimizer: [
        new (require('terser-webpack-plugin'))({
          terserOptions: {
            compress: {
              drop_console: true,
              drop_debugger: true
            }
          }
        })
      ]
    },
    externals: {
      'aws-sdk': 'aws-sdk' // Lambda环境自带AWS SDK，无需打包
    }
  };
  

• 拆分Lambda专用代码
  每个Lambda函数单独作为入口，避免将所有Lambda代码打包成一个文件，确保每个产物只包含自身需要的模块。

Web客户端MPA项目

• 抽离公共依赖

  module.exports = {
    mode: 'production',
    optimization: {
      usedExports: true,
      splitChunks: {
        chunks: 'all',
        cacheGroups: {
          vendors: {
            test: /[\\/]node_modules[\\/]/,
            name: 'vendors',
            chunks: 'all'
          },
          shared: {
            test: /[\\/]packages[\\/]shared[\\/]/,
            name: 'shared',
            chunks: 'all',
            priority: 10 // 优先抽离共享工具包
          }
        }
      }
    }
  };
  

3. PNPM工作区配置 #

• 在pnpm-workspace.yaml中明确工作范围：

  packages:
    - 'packages/*'
    - 'apps/*'
  

• 子项目引用共享工具包时使用workspace:*：

  {
    "dependencies": {
      "shared-utils": "workspace:*"
    }
  }
  

• 控制依赖hoisting：避免全局hoist不必要的依赖，在.npmrc中设置：

  public-hoist-patterns[]=*eslint*
  public-hoist-patterns[]=*prettier*
  

三、缩小构建体积的具体优化步骤 #

1. 分析产物体积
   安装webpack-bundle-analyzer，添加到Webpack配置中：

   const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
   
   module.exports = {
     plugins: [new BundleAnalyzerPlugin()]
   };
   

   运行构建后查看可视化报告，定位体积过大的模块（比如是否bignumber.js被全量打包，或共享工具包中未使用的代码被包含）。

2. 优化依赖导入

   • 对于bignumber.js，如果仅用到部分功能，尝试导入最小子集：

     // 替代全量导入
     import BigNumber from 'bignumber.js/bignumber';
     

   • 共享工具包中仅导出子项目需要的方法，避免导出未使用的模块。

3. 动态导入与代码拆分

   • 对于Lambda函数中可选执行的逻辑，使用动态导入：

     async function handleEvent(event) {
       if (event.type === 'special') {
         const { specialHandler } = await import('./special-handler');
         return specialHandler(event);
       }
       // 常规逻辑
     }
     

   • Web客户端MPA中，对非首屏渲染的页面或组件使用动态导入，减少首屏体积。

4. 替换大体积依赖
   评估是否可用更小的替代库：比如用decimal.js-light替代bignumber.js（体积约为后者的1/3），或使用@ethersproject/bignumber等专用库。

5. 清理无用代码

   • 共享工具包中删除未使用的函数、依赖；
   • 子项目中删除未引用的模块，避免Webpack打包冗余代码。

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