老旧Angular+Node.js项目依赖解析问题及更新最佳实践咨询

优先处理的依赖项 #

你当前遇到的ERESOLVE依赖树冲突，核心矛盾是mongoose-unique-validator@2.0.3仅支持mongoose@^5.2.1，和项目中已安装的mongoose@6.0.1不兼容，优先升级mongoose-unique-validator到适配mongoose 6.x的版本：

• 该包3.0.0及以上版本已适配mongoose 6.x，你可以先单独执行npm i mongoose-unique-validator@latest安装兼容版本，先解决当前的依赖安装阻塞问题。

老旧Angular项目标准化升级流程 #

处理完当前阻塞问题后，按照以下优先级推进全项目升级，避免一次性全量更新导致的大量报错无法定位：

1. 先升级核心框架全家桶，再升级第三方依赖
   • 严格遵循Angular官方跨版本升级规则，逐大版本迭代，不要跳级升级：比如当前是Angular 10，先升到11，再升12，以此类推，每次升级完运行一次ng serve验证基础功能正常，记录每个版本的破坏性变更调整点
   • 同版本的Angular核心包（@angular/common、@angular/core、@angular/cli、@angular/material等）必须保持版本号完全一致，避免框架内部兼容性问题
2. 核心依赖验证完成后，再升级业务类第三方包
   • 先升级下载量高、维护活跃的包，再处理小众、长期未更新的包：如果遇到长期未维护、不支持高版本Angular的包，直接寻找替代方案，不要硬做兼容
3. 依赖全部升级完成后，再处理语法弃用、API变更相关的代码报错

升级过程注意事项 #

• 每次升级单个/单组关联依赖前，先提交一次Git版本，避免升级失败后无法快速回退
• 执行npm install如果遇到依赖树冲突，不要直接加--force或者--legacy-peer-deps参数强制执行，先排查冲突的依赖版本适配关系，从根源解决兼容问题，强制安装会埋下运行时隐患
• 升级完成后要全量跑单元测试、E2E测试，验证核心业务流程没有被破坏性变更影响
• 不要用ncu -u直接全量更新所有依赖的版本号，该操作会直接跳过版本适配校验，是本次更新失败的核心原因

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