如何将GitLab合并请求作为npm模块使用：实现package-a依赖未合并代码的package-b进行预测试

作为日常开发经常碰到这种跨包调试的场景，我给你整理了几个靠谱的方法，按需选择就行：

方法一：本地npm link（最适合实时调试） #

这是本地开发调试跨包依赖最常用的方式，能让package-a直接引用你本地正在修改的package-b代码，修改后实时生效：

• 第一步：进入package-b的本地项目目录，执行：

  npm link
  

  这会把当前package-b的版本注册到本地npm的全局链接里。
• 第二步：切换到package-a的项目目录，执行：

  npm link package-b
  

  现在package-a就会使用你本地的package-b代码了，你在package-b里做的任何修改，package-a都能立即感知到。
• 调试完成后，记得取消链接避免影响后续开发：
  • 在package-a目录执行 npm unlink package-b
  • 在package-b目录执行 npm unlink

方法二：临时修改依赖指向feature分支（适合共享测试或非本地场景） #

如果你的package-b已经把变更推送到了GitLab的feature分支，可以直接修改package-a的package.json依赖，临时指向这个分支：

• 找到package-a的package.json里的package-b依赖项，把原来的trunk分支替换成你的feature分支，比如：

  "dependencies": {
    "package-b": "git+ssh://git@your-gitlab-instance.com/your-group/package-b.git#your-feature-branch"
  }
  

• 执行安装命令更新依赖：

  npm install
  # 或者更精准的更新：npm update package-b
  

• 测试完成后，记得把依赖改回原来的trunk分支，避免误提交到代码仓库。

方法三：使用npm pack打包本地版本（适合模拟正式安装场景） #

如果你想验证package-b打包后的产物是否能正常被package-a使用，可以用这个方法：

• 在package-b的feature分支目录，先执行构建命令（如果有需要的话，比如npm run build），然后执行：

  npm pack
  

  这会在当前目录生成一个类似package-b-1.0.0.tgz的压缩包，包含了打包后的所有文件。
• 切换到package-a目录，执行安装这个本地压缩包的命令：

  npm install ../path/to/package-b-1.0.0.tgz
  

  这样package-a就会安装你本地打包的package-b版本，和正式发布后的安装效果一致。

额外注意事项 #

• 如果package-b需要编译/构建才能生成可用代码，不管用哪种方法，都要确保先执行对应的构建命令，不然package-a可能会引用未编译的源码导致报错。
• 测试完成后一定要恢复依赖配置和本地链接状态，避免影响后续的正常开发流程。

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