Monorepo场景下如何安装本地依赖的devDependencies？

我完全理解你的痛点——用file:路径引用Monorepo里的本地包时，npm默认不会安装这些依赖包的devDependencies，而Lerna那种把所有devDeps统一放在根目录的方式，又没法满足不同包依赖同一dev依赖不同版本的需求，自己写的preinstall脚本还容易在处理shrinkwrap时出问题。下面给你几个更可靠的解决方案：

方案1：使用npm原生Workspaces（推荐，npm v7+） #

npm从v7开始原生支持Monorepo Workspaces，完美适配你的场景，不需要额外工具就能自动处理所有包的依赖（包括每个包独立的devDependencies）：

1. 在根目录的package.json中添加workspaces字段，指定你的包目录：

{
  "name": "your-monorepo-root",
  "workspaces": [
    "packages/*" // 匹配packages下所有子包
  ]
}

2. 把各个子包中依赖其他本地包的file:路径替换成普通的包名依赖，比如将：

"dependencies": { "@reggi/command": "file:packages/command" }

改成：

"dependencies": { "@reggi/command": "^1.0.0" } // 版本号和子包package.json里的保持一致即可

3. 在根目录执行npm install，npm会自动：
   • 安装所有子包的dependencies和devDependencies
   • 在根目录生成统一的node_modules，同时保留各个子包的版本独立性
   • 自动关联本地包的引用，不需要手动用file:路径

优点：原生支持无额外依赖，自动处理所有依赖类型，完美兼容每个包的版本需求，不需要复杂脚本。
缺点：需要升级到npm v7或以上版本。

方案2：用pnpm替代npm（Monorepo友好型包管理器） #

pnpm对Monorepo的支持从设计之初就很完善，不仅安装速度更快、磁盘占用更小，还能完美保留每个包独立的devDependencies版本：

1. 在根目录创建pnpm-workspace.yaml文件：

packages:
  - 'packages/*'

2. 和npm workspaces一样，把本地包的file:依赖替换成包名引用。
3. 执行pnpm install，pnpm会：
   • 为每个子包安装专属的devDependencies
   • 高效共享公共依赖，避免重复安装
   • 自动关联本地包的引用

优点：依赖安装效率高，对Monorepo的支持比npm更成熟，天然处理版本冲突问题。
缺点：需要团队统一切换到pnpm包管理器。

方案3：优化你的preinstall脚本（兼容旧版npm） #

如果暂时无法升级npm或换包管理器，可以优化现有脚本的稳定性，避免shrinkwrap相关的问题：

优化思路： #

• 先备份每个子包的package.json到临时文件
• 合并devDependencies到dependencies时，只追加不覆盖已有依赖
• 安装完成后自动恢复原文件，同时处理安装中断的异常情况

示例Node.js脚本（放在scripts/merge-dev-deps.js）： #

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

const packagesDir = path.join(__dirname, '../packages');

// 备份并修改子包package.json
async function preparePackages() {
  const packageFolders = await fs.readdir(packagesDir, { withFileTypes: true });
  for (const folder of packageFolders) {
    if (!folder.isDirectory()) continue;
    const pkgPath = path.join(packagesDir, folder.name, 'package.json');
    const backupPath = `${pkgPath}.backup`;
    
    // 读取原文件并备份
    const pkgContent = await fs.readFile(pkgPath, 'utf8');
    await fs.writeFile(backupPath, pkgContent, 'utf8');
    
    // 合并devDependencies到dependencies
    const pkgJson = JSON.parse(pkgContent);
    if (pkgJson.devDependencies) {
      pkgJson.dependencies = { ...pkgJson.dependencies, ...pkgJson.devDependencies };
      delete pkgJson.devDependencies;
      await fs.writeFile(pkgPath, JSON.stringify(pkgJson, null, 2), 'utf8');
    }
  }
}

// 恢复原文件（放在postinstall脚本）
async function restorePackages() {
  const packageFolders = await fs.readdir(packagesDir, { withFileTypes: true });
  for (const folder of packageFolders) {
    if (!folder.isDirectory()) continue;
    const pkgPath = path.join(packagesDir, folder.name, 'package.json');
    const backupPath = `${pkgPath}.backup`;
    
    if (await fs.access(backupPath).then(() => true).catch(() => false)) {
      await fs.copyFile(backupPath, pkgPath);
      await fs.unlink(backupPath);
    }
  }
}

// 根据脚本执行时机判断是准备还是恢复
if (process.argv.includes('restore')) {
  restorePackages().catch(err => console.error('恢复package.json失败:', err));
} else {
  preparePackages().catch(err => console.error('处理package.json失败:', err));
}

根package.json配置： #

{
  "scripts": {
    "preinstall": "node ./scripts/merge-dev-deps.js",
    "postinstall": "node ./scripts/merge-dev-deps.js restore"
  }
}

优点：不需要换工具，基于现有npm流程改造。
缺点：仍可能存在安装中断导致文件未恢复的情况，需要额外处理异常。

方案4：使用Rush.js（大型Monorepo专属工具） #

如果你的Monorepo规模较大，依赖关系复杂，可以试试微软的Rush.js——专门为大型Monorepo设计的依赖管理工具，能严格处理版本冲突，同时保留每个包的devDependencies独立性：

1. 全局安装Rush：npm install -g @microsoft/rush
2. 初始化Rush：rush init
3. 按照Rush的配置文档，把你的packages目录添加到配置中
4. 执行rush update，Rush会自动安装所有包的依赖（包括devDependencies），并生成统一的锁文件

优点：适合大型项目，依赖管理严谨，解决版本冲突能力强。
缺点：学习成本较高，配置相对繁琐，小型项目没必要。

总的来说，优先推荐npm Workspaces或pnpm，这两个方案最省心，能从根本上解决你的问题，不需要维护复杂的脚本。

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