npm@7环境下运行npm install时已发布包优先级高于workspaces吗？

你遇到的现象本质 #

你遇到的并不是“npm完全忽略本地workspace，先去registry拉包”的逻辑偏差，而是npm workspaces内置的已发布版本优先规则导致的：只要你本地workspace包的版本号，已经在配置的私有/公共registry上存在，npm就不会把这个本地目录当成依赖解析的优先候选源。哪怕你改光了本地目录下的package.json配置，最终解析流程还是会完全复用registry上对应版本的包信息，自然报出来的错和之前没引入workspaces的时候一模一样。

npm 判定包来源的固定优先级 #

npm解析依赖来源的顺序是硬编码的，没有随机选择的空间，从高到低依次是：

• 依赖声明里明确写了的本地路径/文件协议（比如"my-lib": "file:../packages/my-lib"）会被直接使用，完全不受registry上的版本影响
• 针对根目录workspaces字段扫到的本地包，只有当这个本地包的版本号在当前能访问的registry上查不到的时候，才会被拉进优先匹配的候选列表：如果依赖的包名和本地workspace包完全对得上，且本地版本能满足依赖写的版本范围，npm会直接链本地目录当安装源，根本不去registry拉
• 只要本地workspace包的版本号已经在registry上存在了，npm就把这个目录当成普通的项目文件，不会主动拿本地的替换registry上已经存在的同名同版本包的安装源
• 最后才会依次匹配全局缓存、其他不在workspaces定义里的本地路径依赖

这套逻辑是npm的有意设计，核心原因很实际 #

• 从根源上保障构建可复现性：如果只要本地有同名目录就强制优先用，哪怕版本号和registry完全一样，不同开发者没提交、没发布的本地改动都会让依赖树变得乱七八糟，最后出现“我本地能跑，CI直接挂”的经典问题。这套规则能保证只要版本号没有对应的发布记录，开发环境和线上的依赖解析逻辑是完全一致的
• 兼容团队原来的私有源发布流程：很多团队在接workspaces之前，都是靠把包发到私有源实现跨包引用的。如果接了workspaces就直接把所有registry上存在的版本替换成本地目录的链接，会直接打乱团队已经跑顺的依赖流程，带来一堆没预期的破坏性问题
• 保证peer依赖校验是准确的：peer冲突检测本来就应该基于实际发布到registry的包配置来做，如果优先拿本地还没发布的包做校验，最后报出来的冲突结果和真实发布环境的情况根本对不上，校验就失去意义了

迁移时的适配方法 #

搞懂规则之后，你现在的问题就很好解决：

• 每次改完本地workspace包的内容，把版本号改成一个还没发到私有源的新版本，npm自动就会把这个本地包当可用的workspace源，跳过registry拉取，直接读你改的package.json配置
• 临时需要强制优先用本地workspace的时候，跑npm install加上--install-links参数，就能跳过registry的已发布版本校验，直接把所有路径匹配的本地包链进来
• 整个迁移过程中可以在根目录的.npmrc里写install-links=true，永久开本地优先的链接规则，省得每次输命令加参数

提醒：install-links只适合本地开发用，上CI、生产环境的时候别长期开，不然会破坏构建的可复现性

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