如何在Spring Boot + Angular混合项目架构中保持Angular版本一致

核心疑问解答 #

不需要一次性将所有Angular文件夹全部检出到独立工作区再升级，可以分阶段操作降低风险。使用Angular Workspaces确实能从根本上解决多项目依赖版本不一致导致的兼容问题，是适配你场景的可行解决方案。 #

前置排查步骤 #

先解决当前已经出现的兼容问题，再考虑迁移：

• 核对所有项目的Angular核心三件套版本规则：@angular/cli、@angular/core、@angular/material三者的主版本号必须完全一致，比如16.x的core必须搭配16.x的cli和material，跨主版本必然出现兼容报错。
• 逐个导出每个项目的package.json依赖列表，把不匹配版本的依赖先做标记，后续迁移时统一修正。

Angular Workspaces迁移+升级实操步骤 #

1. 初始化目标版本工作区 #

用你要升级到的目标Angular版本的CLI生成空工作区，根目录会维护统一的核心依赖，所有子项目复用该版本，避免分散管理的版本混乱问题：

# 确保全局安装的Angular CLI是目标版本，比如要升级到16就先装@angular/cli@16
ng new angular-all-workspace --no-create-application

2. 分批次迁移项目 #

不要一次性迁移所有项目，先选一个非核心的边缘项目做试点：

• 将原有项目的src目录、项目专属的配置文件（比如tsconfig.app.json、polyfills.ts等）迁移到工作区的projects/[项目名]目录下
• 项目专属的第三方依赖放到projects/[项目名]/package.json里，Angular核心相关的依赖全部复用工作区根目录的package.json配置，不要在子项目里单独声明Angular核心依赖
• 试点项目跑通构建、测试全流程后，再逐步迁移剩余项目

3. 后续版本升级操作 #

迁移完成后所有项目的Angular核心依赖完全统一，后续升级只需要在工作区根目录操作一次即可：

• 升级前提交所有未提交的代码，避免升级出错无法回滚
• 不要跨多个主版本升级，比如从12升级到17要按12→13→14→15→16→17的顺序逐版本升级，每升级一个版本就运行ng update对应版本的依赖，跑通所有项目的测试用例后再升下一个版本
• 遇到Material API变更直接对照对应版本的更新说明调整代码即可

临时替代方案（暂时不想迁Workspaces时可用） #

如果暂时不想做全量迁移，可以给每个项目单独配置局部的Angular CLI，不要用全局CLI启动/构建项目，在每个项目的package.json的scripts里添加对应命令：

{
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build"
  }
}

后续操作都用npm run start/npm run build而不是全局的ng命令，也能避免不同项目的CLI版本冲突。 #

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