使用npm workspaces的Monorepo：添加包间依赖后Lerna version失败

我来帮你梳理清楚这个问题的根源和正确的操作流程：

为什么会出现安装失败？ #

当你执行lerna version时，Lerna的默认行为是将内部依赖的版本号更新为升级后的具体版本（比如把child里的"parent": "*"改成"parent": "^0.2.14"），这是为了确保发布的包依赖的是明确的内部包版本。但问题出在Lerna后续自动执行的npm install——npm会尝试从远程npm仓库拉取尚未发布的parent@0.2.14，自然会失败。

正确的操作方式 #

你完全不需要手动先发布parent再更新child，Lerna本身就内置了处理内部依赖发布顺序和本地链接的机制，只需调整几个操作步骤：

1. 用lerna bootstrap替代npm install处理本地依赖
   开发和版本升级后的本地环境，不要用npm install，而是执行：

   lerna bootstrap
   

   它会自动识别内部包依赖，直接在本地创建软链接，完全不需要依赖远程仓库的已发布版本，完美解决找不到未发布版本的问题。

2. 版本升级与发布的完整流程

   • 执行版本升级：

     lerna version --conventional-commits
     

     确认版本升级后，Lerna会自动更新所有包的package.json（包括child的parent依赖版本）。
   • 本地验证（可选）：用lerna bootstrap确保依赖链接正常，然后运行构建或测试命令。
   • 发布包：

     lerna publish
     

     Lerna会自动分析包之间的依赖关系，先发布被依赖的parent@0.2.14，再发布依赖它的child@0.1.14，确保child发布时，parent的新版本已经在npm仓库可用。

你的其他疑问解答 #

• 是否需要先发布parent再更新child？
  不需要，Lerna publish会自动处理发布顺序，优先发布被依赖的包，你只需要执行一次发布命令即可。
• 遇到变更时是否都要优先发布依赖包？
  不用手动处理，Lerna会自动识别依赖树并按正确顺序发布，避免了手动发布的繁琐和出错风险。
• 是否需要删除根目录的package-lock.json？
  一般不需要，但如果之前的lock文件是通过npm install生成的，可能存在与内部软链接不兼容的问题。如果遇到依赖冲突或安装异常，可以删除根目录和子包的package-lock.json，然后重新执行lerna bootstrap生成正确的依赖锁文件。

关于依赖版本写法的补充 #

你原本期望用"*"保留依赖的灵活性，但Lerna的版本管理逻辑默认会将内部依赖更新为具体的版本号，这是为了确保发布的包依赖版本明确，避免后续意外拉取不兼容的版本。如果你坚持要保留"*"，需要自定义Lerna的版本更新策略，但这并不推荐，会增加版本不一致的风险。

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