Angular CLI：超越ng serve——生成器、目标配置、缓存及构建统计信息
了解可免除繁琐工作的 Angular CLI 选项：生成器标志、内置帮助、项目专用命令、ng run 目标、缓存清理以及构建统计信息。
大多数 Angular 开发者一开始就会使用四个命令：ng serve、ng build、ng generate 和 ng test，之后便不再涉足其他工具。这对小型应用来说足够了，但随着项目规模扩大，手动编写样板代码、查找版本号、估算包大小以及处理损坏的缓存所耗费的时间会越来越多。CLI 已经为这些任务提供了解决方案。本指南将介绍值得养成习惯的选项，说明每个选项在何时能发挥作用，并最终给出一个可直接采用的简洁日常工作流程。
如果您仍处于创建项目环境的阶段，搭建现代 Angular 项目的指南涵盖了相关内容；以下所有内容均假设项目已经存在。
更充分地利用 ng generate
这个生成器就是大家所熟知的完整命令形式：
ng generate component user-profile
每个生成器都有简写别名，因此 generate 变为 g，component 变为 c：
ng g c user-profile
真正的优势在于各种标志选项。当某个小型展示组件无需专门的规范文件时，--skip-tests 可以防止命令行工具生成该文件：
ng g c user-profile --skip-tests
默认情况下，每个组件都会被保存在独立的文件夹中。而 --flat 选项则会让文件直接写入当前目录，这非常适合那些与父组件位于同一位置的微型组件：
ng g c user-profile --flat
这些标志选项可以组合使用，因此你可以同时要求应用多个功能：
ng g c user-profile --flat --skip-tests
这些选项同样适用于服务、指令、管道、守卫以及其他架构模板。让生成器负责创建文件，可以确保团队内的命名和布局保持一致。添加 --dry-run 可以在不实际写入任何内容的情况下预览架构模板会生成的内容。
直接询问 CLI 而非在网络上搜索
了解生成器功能的最快方法就是直接询问它。这样就能列出所有可用的架构模板：
ng generate --help
别名的工作方式也是如此：
ng g --help
在特定架构模板后添加 --help，即可显示该模板的所有选项及其简短描述：
ng g component --help
不同版本中的选项会有所变化，而论坛上的答案往往描述的是旧版本的标志；帮助信息始终与项目中安装的 CLI 版本一致。
使用 ng config 读取和修改设置
工作区配置存储在 angular.json 中，人们很容易直接编辑该文件。CLI 提供了用于读取和写入这些值的命令：
ng config
单独调用该命令会输出配置内容，以便查看当前设置的值：
ng config
你还可以传入 JSON 路径来读取某个值，或传入路径后跟值来设置该值，例如更改整个工作区的 CLI 选项。在脚本中，使用可重复的 ng config 命令比手动编辑 JSON 更可靠：既然 CLI 能管理文件，那就用 CLI 来修改它。
使用 ng 版本报告你的环境信息
当出现问题时，准确的版本信息非常重要。无需打开 package.json 逐一查找，可直接运行：
ng version
或其简写形式：
ng v
输出内容会将 Angular CLI 版本、已安装的 Angular 包、Node.js、包管理器以及操作系统集中显示在一段文字中。当你向同事或维护人员寻求帮助时，这正是他们所需要的信息。仅说明项目无法运行的报告根本无法为他们提供任何线索，而直接粘贴以下命令的输出就能提前回答他们前五个问题：
ng version
直接测量生产环境下的打包文件，而非凭猜测
这个构建标志的实际使用频率远低于其潜力：
ng build --stats-json
它会生成一个统计文件，描述每个输出块的内容。将此文件输入到打包分析工具中，即可直观地查看字节的来源分布。需要注意的是，文件格式取决于所使用的构建工具：基于webpack的旧版构建会生成webpack统计信息，而基于esbuild的新版应用构建工具则会输出esbuild元数据，因此请选择能够识别对应构建工具输出的分析工具，并查阅您所用版本的Angular官方文档。
当应用运行速度较慢时，常见的问题包括：
- 存在某个体积过大的第三方库
- 某些代码块的体积远超预期
- 同一依赖被多次打包进应用中
- 初始加载时带入了过多体积较大的组件
- 延迟加载的功能最终体积超过了预期
仅凭源代码本身是无法看到这些信息的。通过比较依赖项升级前后的统计数据，可以低成本地发现功能退化问题。
重新安装所有内容前请清除构建缓存
CLI会维护一个持久化的磁盘缓存，以便加快重复构建的速度。ng cache命令用于管理该缓存；ng cache info则可以显示缓存的存储位置以及是否已启用：
ng cache
当构建行为出现异常时，清除该缓存往往是解决问题的方法：
ng cache clean
在依赖项变更、Angular升级，或在不同版本包的分支之间切换后，过期的缓存条目往往会出现。清除缓存只需几秒钟，因此请先尝试此方法，再考虑采用删除node_modules并重新安装的繁琐方式。
在本地及CI环境中进行代码检查
如果项目中配置了代码检查工具，可通过以下命令运行它：
ng lint
较新版本的 Angular 默认不包含代码检查工具，因此必须先添加相应的工具（通常是通过 Angular ESLint 集成），才能使用 ng lint 命令。配置完成后，它能在审阅者发现以下问题之前就将其捕获：
- 未使用的变量和导入
- 格式不一致问题
- 潜在的错误
- 不推荐的编码模式
- 整体代码质量问题
在 CI 流水线中运行相同命令，可以确保有问题的代码在进入主分支之前就被标记出来，无需依赖人们是否记得执行该命令。
在自动化流程中一次性运行测试
在本地环境中，测试通常处于监视模式，每次保存文件时都会重新运行：
ng test
CI 任务无需使用会等待文件变化的进程。关闭监视模式后，命令只会运行一次测试套件然后立即退出：
ng test --watch=false
退出码用于反映测试是否通过，而流水线正是根据该代码将任务标记为绿色或红色。处于监控模式的流水线会一直等待直到超时。本地开发和持续集成有不同的需求，一个命令行界面无需同时满足两者。
在多项目工作区中指定单个项目
较大的 Angular 仓库通常会在一个工作区内包含多个应用程序和库。大多数命令都接受项目名称作为参数，因此你可以仅构建其中一个应用：
ng build my-app
或仅测试其中一个：
ng test my-app
在单仓库式工作区中，这类操作已变得十分常见：
ng build admin
ng build customer
ng test shared-ui
处理共享的 UI 库时无需重新构建每个应用；通过限定命令范围可以缩短反馈循环的时间。
使用 ng run 调用任意架构目标
在那些常见的命令背后，还有一个更通用的命令，但很少有开发者会直接使用它：
ng run
它会根据工作区配置中的命名架构目标来执行任务，采用 project:target 的格式，可选地还会附加一个配置名称：
ng run my-app:build
这些标准命令实际上是常见目标的快捷方式。一旦工作区定义了自定义目标，比如用于生成代码、部署预览或运行特定测试环境的工具，ng run 就会变得非常有用。可以将其理解为“精确执行该项目的这个目标”，不会自动推断其他内容。
从终端打开文档
当需要快速查看某个 API 时，CLI 可以帮您开始搜索：
ng doc
只需提供一个关键词，它就会在官方的 Angular 文档中查找相关信息：
ng doc signals
请注意，结果会在浏览器中显示而非在终端打印，因此这只是通往对应页面的快捷方式，并非离线参考资料。
让帮助功能替代死记硬背
或许最有用的习惯就是使用这条命令：
ng help
它会列出所有顶级命令。如需查看某个特定命令的选项，可添加 --help：
ng build --help
对于生成器也是如此，甚至只需查看单个示意图即可：
ng generate service --help
没人需要记住所有的标志位。高效的开发者并非那些能记住一切的人，而是那些一旦忘记就知道去哪里查找的人。
整合这些功能的日常工作流程
一个实用的常规操作可能如下所示。首先启动开发服务器：
ng serve
在开发功能时，使用相应的标志来生成所需内容：
ng g c profile --skip-tests
在提交代码之前，先进行代码检查并运行一次测试：
ng lint
ng test --watch=false
对于生产环境构建，应明确使用生产配置：
ng build --configuration production
当担心代码包大小时，生成相关统计信息：
ng build --stats-json
当构建过程出现异常时，先清除缓存：
ng cache clean
每当忘记某个选项时，直接询问命令本身：
ng <command> --help
总结
Angular CLI 是围绕整个开发流程设计的效率提升工具，其最大优势在于通过几个选项来消除重复性工作：
- 使用标志生成代码，无需手动编写样板代码
- 在多项目工作空间中将命令限制在单个项目中使用
--help 命令，它总能匹配到你当前安装的版本下次在 Angular 项目中打开终端时，请记住：ng 背后还有许多更多功能：
ng serve