如何高效协作开发存在依赖关系的多个npm包？

针对你遇到的依赖联调、多环境一致性、版本冗余问题，按适配优先级给出可直接落地的方案：

方案1：pnpm workspace + Changesets（最推荐，覆盖所有痛点） #

你之前踩的npm/yarn workspace、npm link的坑，本质是这几个工具的软链接管理逻辑太粗糙：全局链接冲突、依赖提升时跳过链接包的依赖解析、执行install时随意覆盖链接关系，和webpack等工具的模块解析规则不匹配。pnpm从设计上就规避了这些问题，它的依赖目录是严格的嵌套软链接结构，和你正常从npm源安装包的目录结构完全一致，不会出现找不到模块、链接莫名失效的问题。

配置步骤 #

1. 在main项目根目录新建pnpm-workspace.yaml，声明本地包路径：

packages:
  # 如果要把A、B纳入main项目的代码库做monorepo管理（最适合强关联的内部包），就把A、B放到packages目录下
  - "packages/*"
  # 如果要保留A、B独立仓库、本地单独存放，直接写本地相对路径即可
  # - "../A"
  # - "../B"

2. 把main、B中对A的依赖版本，以及main中对B的依赖版本统一写成workspace:*，执行pnpm install后，pnpm会自动完成本地包的链接，修改A/B的代码会直接在main中生效，不需要任何发布、拷贝操作。
3. 解决CI/CD和团队协作问题：搭配Changesets做版本管理，完全不需要每次小改动就发正式版本。
   • 本地开发阶段不需要做任何版本操作，改完代码直接调试即可
   • 需要给团队成员、CI环境同步改动时，执行pnpm changeset标记改动级别（patch/minor/major），再用snapshot模式发布带临时标识的预览版本（比如1.2.3-dev-20240520-xxxx）到私有源，这类临时版本可以设置定期清理规则，不会在仓库留下冗余的无意义版本记录
   • 等迭代功能全部验证稳定后，再统一生成正式版本号发布即可

你担心的私有源产生大量冗余版本的问题，用这套方案完全可以避免：临时开发版本统一加-dev-[时间戳]后缀，在私有源上配置规则自动删除超过7天的dev版本即可，仓库里只会保留正式发布的稳定版本，不会有冗余垃圾版本。

方案2：依赖版本强制覆盖（保留git依赖习惯，最小改动） #

你之前遇到的git依赖无法递归解析的问题，不需要换工作流，直接用包管理器的依赖覆写能力就能解决，不需要额外工具：
在main项目的package.json中添加配置，强制所有层级（包括B依赖的A）的A包都解析到你指定的git地址版本：

// 用pnpm/yarn时添加
{
  "pnpm": {
    "overrides": {
      "A": "git+https://你的A仓库地址.git#开发分支名"
    }
  },
  "resolutions": {
    "A": "git+https://你的A仓库地址.git#开发分支名"
  }
}

// 用npm 8.3以上版本时添加
{
  "overrides": {
    "A": "git+https://你的A仓库地址.git#开发分支名"
  }
}

配置完成后重新执行install，不管是直接依赖还是嵌套依赖的A，都会被替换成你指定的git版本，不会出现B目录下找不到A的问题。所有团队成员、CI环境只需要正常执行npm update/pnpm install就能拉到最新的A/B代码，不需要配置本地目录结构。

方案3：本地联调工具+提交校验（零配置改造成本） #

如果不想调整现有依赖声明，继续用yalc做本地联调也可以，只要做好提交规则即可：

1. 在项目.gitignore中添加.yalc、yalc.lock，忽略yalc生成的本地文件
2. 加pre-commit钩子校验package.json中的依赖声明，禁止把file:、link:开头的本地依赖提交到git仓库，提交前自动把依赖版本切回正常的版本号
3. 本地开发时用yalc push把A/B的改动同步到main项目，不需要发布版本；提交到仓库的依赖声明都是正常可被CI解析的地址，其他成员不需要配置和你一致的本地结构。

不推荐继续用npm link：npm link的软链接是全局注册的，不同项目链接同一个包的不同版本时会出现冲突，执行install、update命令时很容易被覆盖，兼容性问题远多于上述方案。

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