Webpack构建生产包时能否检测并警告引入的devDependencies？

Webpack原生不支持该检测能力——构建时Webpack不会区分依赖属于dependencies还是devDependencies，只要模块可解析就会纳入打包流程，但通过现有插件或少量自定义代码，可以完全实现「生产构建引入dev依赖（含直接声明、lockfile标记的间接依赖）时自动告警」的需求，完全适配你提到的nx monorepo场景。

快速落地：使用现有插件 #

如果不想写自定义逻辑，可以直接用社区插件满足基础需求：

• 仅需检测直接引入的dev依赖：用webpack-node-externals，在生产配置中将所有devDependencies下的包配置为非外部引入的校验目标，一旦构建时解析到这些包被业务代码引用，就会直接抛出模块解析警告。该方案配置简单，但无法识别间接引入的、在package-lock.json中标记dev: true的依赖。
• 需要覆盖间接依赖检测：使用depcheck-webpack-plugin，配置checkDevDeps: true规则，插件会自动对比构建产物中的所有依赖和lockfile中的dev标记，命中后抛出对应警告，支持配置白名单放过特殊场景。

灵活适配：自定义轻量插件（推荐nx monorepo场景使用） #

你的项目是单根package.json的nx monorepo结构，没有子包独立的依赖声明，写个几十行的自定义插件适配成本最低，还能完全贴合自己的校验规则，核心逻辑如下：

1. 构建启动时读取根目录package.json收集直接声明的dev依赖，同时读取package-lock.json遍历所有依赖节点，把所有标记dev: true的包存入集合
2. 挂载到Webpack构建钩子，在模块解析完成后遍历所有进入构建流程的第三方模块
3. 提取模块对应的包名，和dev依赖集合做比对，命中则通过Webpack原生接口抛出带引入路径的警告

最小可用代码示例：

const fs = require('fs');
const path = require('path');

class DevDepCheckPlugin {
  constructor(opts = {}) {
    this.devDepSet = new Set();
    const rootPath = opts.root || process.cwd();
    // 读取直接声明的开发依赖
    const pkg = JSON.parse(fs.readFileSync(path.join(rootPath, 'package.json'), 'utf8'));
    Object.keys(pkg.devDependencies || {}).forEach(depName => this.devDepSet.add(depName));
    // 读取lockfile中标记为dev的所有间接依赖
    const lockData = JSON.parse(fs.readFileSync(path.join(rootPath, 'package-lock.json'), 'utf8'));
    const traverse = (depMap) => {
      if (!depMap) return;
      Object.entries(depMap).forEach(([name, info]) => {
        if (info.dev) this.devDepSet.add(name);
        traverse(info.dependencies);
      })
    };
    traverse(lockData.dependencies);
    this.whiteList = new Set(opts.whitelist || []);
  }
  apply(compiler) {
    compiler.hooks.compilation.tap('DevDepCheckPlugin', (compilation) => {
      compilation.hooks.finishModules.tap('DevDepCheckPlugin', (modules) => {
        modules.forEach(mod => {
          // 跳过非node_modules的业务源码
          if (!mod.resource || !mod.resource.includes('node_modules')) return;
          // 提取包名，兼容@scope开头的私有包
          const pathSegs = mod.resource.split('node_modules/').pop().split(path.sep);
          const pkgName = pathSegs[0].startsWith('@') ? `${pathSegs[0]}/${pathSegs[1]}` : pathSegs[0];
          if (this.devDepSet.has(pkgName) && !this.whiteList.has(pkgName)) {
            compilation.warnings.push(
              new Error(`[DevDepCheck] 生产构建引入了开发依赖：${pkgName}，引入来源：${mod.issuer?.resource || '构建入口'}`)
            );
          }
        })
      })
    })
  }
}

// 生产配置中引入
module.exports = {
  // ...其他webpack配置
  plugins: [
    new DevDepCheckPlugin({
      root: path.resolve(__dirname, '../../'), // 指向monorepo根目录
      whitelist: [] // 可配置需要放过的特殊包
    })
  ]
}

如果需要强管控，直接把代码里的compilation.warnings改成compilation.errors，就会在命中规则时直接中断构建，避免错归类的依赖被发布上线。

• 插件逻辑默认只校验node_modules下的第三方模块，不会误判apps/*、libs/*下的业务源码
• 可以把该插件配置统一收敛到nx的全局webpack配置里，前端、后端应用的生产构建都会自动生效，不需要每个应用单独配置
• 校验规则和dependabot的allow配置完全对齐后，就能保证所有进入生产包的依赖都在dependabot扫描范围内，不会出现开发依赖漏扫的安全风险

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