如何在Webpack/Rollup中按需打包类方法？实现CMS与产品端分包

嘿，这个需求我之前也碰到过，刚好可以给你分享几个在Webpack和Rollup里都能用的方案，帮你实现XYZ类方法的按需打包：

方案一：环境变量 + Tree Shaking（最推荐） #

这个方法利用打包工具的Tree Shaking特性，配合环境变量来移除未使用的代码，步骤如下：

1. 配置环境变量 #

先在打包配置里定义一个自定义的环境变量，比如BUILD_TARGET，用来区分是CMS还是产品端打包：

Webpack配置示例

// webpack.config.js
const webpack = require('webpack');

module.exports = (env) => {
  const target = env.target || 'product'; // 默认产品端
  return {
    // 其他配置...
    plugins: [
      new webpack.DefinePlugin({
        'process.env.BUILD_TARGET': JSON.stringify(target)
      })
    ]
  };
};

Rollup配置示例

// rollup.config.js
import replace from '@rollup/plugin-replace';

export default (commandLineArgs) => {
  const target = commandLineArgs.target || 'product';
  return {
    // 其他配置...
    plugins: [
      replace({
        preventAssignment: true,
        'process.env.BUILD_TARGET': JSON.stringify(target)
      })
    ]
  };
};

2. 修改XYZ类的代码 #

把类方法改成条件挂载的方式，让打包工具能识别出死代码并移除：

class XYZ {
  constructor() {
    // 仅CMS环境保留forCms方法
    if (process.env.BUILD_TARGET === 'cms') {
      this.forCms = () => {
        // CMS专属逻辑
      };
    }

    // 仅产品环境保留forProduct方法
    if (process.env.BUILD_TARGET === 'product') {
      this.forProduct = () => {
        // 产品端专属逻辑
      };
    }
  }
}

当你执行打包命令时，比如Webpack打包CMS：

webpack --env target=cms

Rollup打包CMS：

rollup --config --target=cms

打包工具会把process.env.BUILD_TARGET替换成'cms'，此时产品端的if判断会变成if ('cms' === 'product')，属于死代码，Tree Shaking会自动移除这段逻辑，最终的打包结果就只会保留forCms方法，反过来打包产品端同理。

⚠️ 注意事项：

• 确保你的代码是ES模块（使用import/export，不是require）
• Webpack要开启生产模式（默认Tree Shaking生效），Rollup默认支持Tree Shaking
• 如果类方法有副作用，需要在package.json里标记"sideEffects": false，或者指定哪些文件有副作用，避免Tree Shaking误删

方案二：拆分文件 + 条件导入 #

如果不想用Tree Shaking，也可以把XYZ类拆分成基础类+不同的方法文件：

1. 拆分代码文件 #

• src/xyz.base.js：基础类，仅包含constructor

export class XYZBase {
  constructor() {}
}

• src/xyz.cms.js：CMS专属方法

import { XYZBase } from './xyz.base.js';

export class XYZ extends XYZBase {
  forCms() {
    // CMS逻辑
  }
}

• src/xyz.product.js：产品端专属方法

import { XYZBase } from './xyz.base.js';

export class XYZ extends XYZBase {
  forProduct() {
    // 产品端逻辑
  }
}

2. 根据环境变量导入对应的类 #

在入口文件里根据环境变量选择导入哪个类：

let XYZ;
if (process.env.BUILD_TARGET === 'cms') {
  XYZ = (await import('./xyz.cms.js')).XYZ;
} else {
  XYZ = (await import('./xyz.product.js')).XYZ;
}

// 后续使用XYZ类

或者在打包配置里直接指定不同的入口文件，比如Webpack的配置根据target切换入口：

module.exports = (env) => {
  const target = env.target || 'product';
  return {
    entry: `./src/entry.${target}.js`,
    // 其他配置...
  };
};

这样每个入口文件导入对应的XYZ类即可。

方案三：Rollup条件导出（适合库开发） #

如果你是开发一个类库，想让使用者可以直接导入不同版本的XYZ类，可以在package.json里配置条件导出：

{
  "name": "your-library",
  "exports": {
    "./cms": "./dist/xyz.cms.js",
    "./product": "./dist/xyz.product.js"
  }
}

然后分别打包出两个版本的文件，CMS团队可以导入your-library/cms，产品团队导入your-library/product，非常直观。

总结 #

如果是项目内部使用，方案一（环境变量+Tree Shaking）最简洁，不需要拆分文件；如果是库开发，方案三的条件导出体验最好；方案二则适合需要更清晰代码分离的场景。

你可以根据自己的项目情况选择合适的方案，试一下应该就能搞定啦～

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