我之前帮团队处理过npm 3到npm 5的迁移问题，你的情况其实是npm 5对node_modules的校验和管理逻辑发生了根本性变化导致的——npm 5引入了package-lock.json来精确控制依赖版本和路径，当它发现node_modules里的依赖是外部创建的符号链接（而非npm自身管理的链接），就会判定这些依赖“不符合预期”，进而在执行install时尝试删除或替换它们。

下面是几个经过验证的解决办法，你可以根据自己的场景选择：

解决办法 #

1. 禁用package-lock.json生成（最直接的兼容方案） #

npm 5默认生成的package-lock.json是问题的核心，它会严格校验每个依赖的路径和哈希值。你可以通过配置关闭它，让npm回到类似npm 3的行为：

• 单个项目永久生效：在项目根目录执行

npm config set package-lock false

• 临时生效：每次执行install时加参数

npm install --no-package-lock

如果需要团队协作，把这个配置写入项目根目录的.npmrc文件，确保所有人的配置一致：

package-lock=false

2. 用postinstall脚本自动修复符号链接 #

如果必须保留package-lock.json（比如需要精确的依赖版本控制），可以在package.json中添加一个postinstall脚本，在npm install完成后重新创建你的符号链接：

{
  "scripts": {
    "postinstall": "bash -c 'for module_dir in /path/to/your/shared/modules/*; do module_name=$(basename \"$module_dir\"); ln -sf \"$module_dir\" \"node_modules/$module_name\"; done'"
  }
}

把/path/to/your/shared/modules替换成你真实存储模块的目录路径，这样每次npm install完成后，脚本会自动把所有需要的符号链接重新建立起来。如果是Windows环境，需要把脚本改成bat格式适配系统。

3. 关闭npm 5的严格校验选项（辅助优化） #

npm 5还引入了更严格的peer依赖检查和审计机制，这些也可能加剧安装时的异常行为，可以尝试关闭：

npm config set strict-peer-deps false
npm config set audit false

同样可以把这些配置写入.npmrc文件，确保团队成员配置统一。

4. 换用pnpm（长期最优解） #

如果你的团队可以接受更换包管理器，pnpm是更好的选择——它本身就是通过符号链接和硬链接来共享依赖的，天生支持你这种“单独维护模块目录+项目通过链接引用”的场景，而且依赖安装速度和磁盘占用都比npm 5更优，能从根本上避免这类问题。

注意事项 #

• 先在单个测试项目上验证方案，确认没问题后再推广到所有项目；
• 如果使用postinstall脚本，要注意不同操作系统的兼容性，比如Windows和Linux/macOS的脚本语法差异。

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