已迁移至pnpm的项目仍用npm执行脚本是否存在潜在隐患？

短时间内这么操作可能不会立刻出问题，但长期来看确实存在不少隐性风险，具体如下：

• 依赖解析逻辑差异引发的隐性bug
  pnpm的node_modules结构和npm不一样——pnpm默认用硬链接存储依赖，即使加了--shamefully-hoist，依赖提升的规则也和npm的扁平化逻辑有区别。npm运行脚本时，会按照自己的模块查找逻辑去node_modules里找包，可能出现某个深层依赖的peer依赖找不到、或者版本不匹配的情况。这类问题不一定会立刻显现，可能在新增依赖、升级依赖，或者在特定环境下才会触发，排查起来很麻烦。

• 脚本执行环境的细微差异
  pnpm和npm在执行脚本时的环境变量、可执行文件路径处理有区别。比如node_modules/.bin目录下的可执行文件，pnpm的调用逻辑和npm不完全一致，有些依赖的脚本可能依赖特定的环境变量（比如缓存路径），用npm执行时可能出现构建失败、测试报错等情况。

• lock文件的维护冲突
  你现在删了package-lock.json，但如果团队里有人不小心跑了npm install，会重新生成这个文件。而pnpm用的是pnpm-lock.yaml，两个lock文件的版本记录会逐渐脱节，导致不同人用不同包管理器装出来的依赖版本不一样，最终引发构建或运行结果不一致的问题，增加团队协作的混乱。

• 长期的技术债务
  延后CI/CD改造看似省了当下的精力，但随着项目迭代，新依赖可能会用到pnpm特有的特性（比如workspace协议、严格的peer依赖处理），而npm无法兼容这些特性，到时候出现的问题会更多。等你再去改CI/CD时，需要排查的历史问题会堆积，反而更费时间。

临时规避建议 #

如果暂时不想动CI/CD，可以先做这几件事降低风险：

• 在项目根目录加个.npmrc文件，写上package-lock=false，防止误操作生成package-lock.json
• 在README里明确提醒所有人：只能用pnpm安装依赖，npm仅用来执行脚本
• 定期用pnpm跑一遍所有脚本（test、build等），确保和npm执行的结果一致，避免隐性差异积累

内容的提问来源于stack exchange，提问作者v-moe