深入解读 Angular CLI 生成的 SSRWebpack项目开发、构建与测试工作流实战【免费下载链接】angular-cliCLI tool for Angular项目地址: https://gitcode.com/gh_mirrors/an/angular-cli本文以 Angular CLI 仓库中的 SSR 项目示例tests/e2e/assets/ssr-project-webpack及其 README.md 为对象系统讲解 Angular CLI 生成项目后开发者日常使用的全部核心工作流本地开发服务器、代码脚手架生成、生产构建、单元测试、端到端测试并进一步剖析该项目作为 Webpack 构建方案 Express CommonEngine 的 SSR 工程在 angular.json 与 server.ts 中的底层实现。读完本文你将掌握ng serve、ng generate、ng build、ng test、ng e2e等命令在真实 SSR 工程中的完整用法以及dev:ssr、build:ssr、serve:ssr、prerender这套 SSR 专属脚本的含义与执行链路。一、这份 README 是什么Angular CLI 生成项目的标准说明书tests/e2e/assets/ssr-project-webpack/README.md并非手写文档而是 Angular CLI 在生成新项目时自动产出的标准 README。其结构与仓库内 packages/schematics/angular/workspace/files/README.md.template 完全对应——该模板由ng new/ng generate application的 workspace schematic 渲染项目名通过% utils.classify(name) %注入CLI 版本通过% version %注入每次新建项目都会得到一份内容一致、可直接上手的指南。这份 README 覆盖了七个标准章节正好对应一个 Angular 项目从开发到上线的完整生命周期章节核心命令用途Development serverng serve启动本地开发服务器并热重载Code scaffoldingng generate component ...按需生成组件等代码骨架Buildng build编译产物到dist/目录Running unit testsng test运行 Karma 单元测试Running end-to-end testsng e2e运行端到端测试Further helpng help查看 CLI 全部命令帮助需要特别说明的是该 README 开头注明项目由 Angular CLI16.2.10生成但其 package.json 中angular/cli、angular/ssr等依赖均为^22.0.0-next.0。这是因为该目录在仓库中扮演的是e2e 测试资产fixture角色它被tests/e2e/tests/update/update-application-builder.ts等测试用例通过createProjectFromAsset(ssr-project-webpack, ...)加载用于验证旧版本生成的 SSR 项目能够被当前版本 CLI 正常升级与构建该测试会断言dist/ssr-project-webpack/server/server.mjs等产物存在。因此阅读本文时命令与配置行为均以仓库当前版本为准。二、Development serverng serve与热重载README 指出运行ng serve启动开发服务器后访问http://localhost:4200/修改任何源文件应用都会自动重载。这是 Angular CLI 基于 Webpack 开发服务器dev-server builder提供的核心体验。从 angular.json 可以看到该项目的servetarget 配置serve: { builder: angular-devkit/build-angular:dev-server, configurations: { production: { buildTarget: ssr-project-webpack:build:production }, development: { buildTarget: ssr-project-webpack:build:development } }, defaultConfiguration: development }几个值得注意的细节serve并不直接负责编译而是委托给buildTarget指向的buildtarget。默认defaultConfiguration: development因此ng serve等价于先以 development 配置构建浏览器产物再启动开发服务器并开启热模块替换HMR与自动重载。development 构建配置在buildtarget 中显式关闭了buildOptimizer、optimization并开启sourceMap: true、namedChunks: true、vendorChunk: true见 angular.json 第 41–48 行目的是换取更快的增量编译与可读的调试信息。若需以生产模式预览可执行ng serve --configuration production此时会使用build:production的优化产物。三、Code scaffoldingng generate与 schematicsREADME 给出的脚手架用法是ng generate component component-name即生成一个名为component-name的组件。同时提示可通过ng generate --help查看所有可用的 schematic 类型。生成器在 Angular CLI 中称为schematic原理图其实现集中在 packages/schematics/angular 目录下。从该目录的 collection 结构可以看到 CLI 内置了远超组件的生成能力每个子目录对应一种可生成物并配有独立的schema.json与index_spec.ts测试component、directive、pipe、class、enum、interface、guard、interceptor、resolver、service、module代码骨架生成application、library、workspace工程级生成app-shell、server、ssr、service-worker、environments、web-worker、tailwind、config专项能力接入migrations/版本升级迁移如update-workspace-config、use-application-builder、migrate-karma-to-vitest。例如ng generate component的 files 模板packages/schematics/angular/component/files会同时产出.ts、.html、.css、.spec.ts四类文件而ng generate --help输出的正是这些 collection 的汇总。所有生成器都遵循统一的模板 schema 校验 变更树机制这也是ng generate能保证产物格式与项目规范一致的根本原因。四、Buildng build与生产优化README 指出ng build将构建产物输出到dist/目录。对本项目而言buildtarget 使用angular-devkit/build-angular:browserbuilder见 angular.json 第 13–51 行build: { builder: angular-devkit/build-angular:browser, options: { outputPath: dist/ssr-project-webpack/browser, index: src/index.html, main: src/main.ts, polyfills: [zone.js], tsConfig: tsconfig.app.json, assets: [src/favicon.ico, src/assets], styles: [src/styles.css], scripts: [] }, configurations: { production: { budgets: [ { type: initial, maximumWarning: 500kb, maximumError: 1mb }, { type: anyComponentStyle, maximumWarning: 2kb, maximumError: 4kb } ], outputHashing: all }, ... }, defaultConfiguration: production }其中值得展开的要点入口与资源main指向 src/main.ts该文件通过platformBrowser().bootstrapModule(AppModule)以 JIT 方式引导浏览器端应用styles、scripts、assets分别声明全局样式、脚本与静态资源。production 配置默认使用production配置启用代码压缩、摇树优化tree shaking、AOT 编译等优化并通过outputHashing: all为产物文件名添加内容哈希以便长效缓存。budgets 预算initial预算对首个加载包设 500kb 警告线 / 1mb 错误线anyComponentStyle对单个组件样式设 2kb / 4kb 预算。当构建产物超出maximumWarning时 CLI 给出警告超出maximumError时构建直接失败——这是控制首屏体积的实用机制。构建产物浏览器侧产物输出到dist/ssr-project-webpack/browser由于本项目的main使用 JIT 引导且构建目标是 Webpack 方案ng build默认生成可被 SSR 服务器复用的 HTML 与 JS 包。ng build的底层实现在仓库的 packages/angular_devkit/build_angular/src/builders 目录browser、dev-server、server、prerender、karma等 builder 均在此处其测试用例packages/angular_devkit/build_angular/src/builders/**/*_spec.ts对 build 输出的文件清单、哈希命名、source map 等行为做了逐项断言可作为深入阅读的入口。五、SSR 专属工作流dev:ssr / build:ssr / serve:ssr / prerender这是本项目与纯客户端项目的核心差异也体现了 package.json 中脚本设计的完整思路scripts: { ng: ng, start: ng serve, build: ng build, watch: ng build --watch --configuration development, test: ng test, dev:ssr: ng run ssr-project-webpack:serve-ssr, serve:ssr: node dist/ssr-project-webpack/server/main.js, build:ssr: ng build ng run ssr-project-webpack:server, prerender: ng run ssr-project-webpack:prerender }结合 angular.json 的server、serve-ssr、prerender三个 target 逐一说明1.build:ssr—— 双段构建ng build ng run ssr-project-webpack:server先构建浏览器产物browserbuilder输出dist/ssr-project-webpack/browser再调用servertargetangular-devkit/build-angular:serverbuilder输出dist/ssr-project-webpack/server。servertarget 的main指向 server.tstsConfig指向 tsconfig.server.json——后者继承tsconfig.app.json额外声明types: [node]并将 src/main.server.ts 与server.ts纳入编译范围。main.server.ts只做一件事导出app.module.server.ts中的AppServerModule。2.serve:ssr—— 启动 Node 服务器node dist/ssr-project-webpack/server/main.jsserver.ts是完整的 Express CommonEngine SSR 服务器其运行逻辑可拆解为四步对应 server.ts 第 11–70 行静态资源将dist/ssr-project-webpack/browser目录以express.static挂载maxAge: 1y做一年长缓存匹配*.*模式Angular 渲染其余所有路由交给CommonEngine.render()传入bootstrap: AppServerModule、documentFilePath优先index.original.html回退index.html、url由protocol host originalUrl拼出绝对地址、publicPath与APP_BASE_HREF端口默认监听process.env.PORT || 4000即http://localhost:4000导出约定通过__non_webpack_require__判断直接运行还是被 require使app()可被无服务器serverless函数直接复用同时避免被当作模块引入时误启动监听。AppServerModule见 src/app/app.module.server.ts通过imports: [AppModule, ServerModule]将浏览器模块与angular/platform-server的ServerModule合并这正是 Angular Universal/SSR 的标准装配方式。CommonEngine的实现位于仓库 packages/angular/ssr 包中node/目录下的引擎源码与测试angular/ssr依赖在 package.json 中声明为^22.0.0-next.0。3.dev:ssr—— SSR 开发模式ng run ssr-project-webpack:serve-ssr对应serve-ssrtargetangular-devkit/build-angular:ssr-dev-serverbuilder同时指定browserTarget与serverTarget默认走development配置提供浏览器端与服务器端同步热重载的 SSR 开发体验。SSR 相关 builder 的更多行为可参考仓库中对应实现与tests/e2e/tests/vite/ssr-*.ts系列 e2e 用例。4.prerender—— 预渲染ng run ssr-project-webpack:prerender对应prerendertargetangular-devkit/build-angular:prerenderbuilderoptions.routes中声明了[/]即构建时把首页预渲染为静态 HTML可结合静态托管获得首屏性能收益。由于本仓库示例未配置AppServerModule之外的路由app-routing.module.ts中routes: []实际项目需在路由配置完整后为每个路由添加预渲染条目。六、单元测试ng test与 KarmaREADME 指出ng test通过 Karma 执行单元测试。在 angular.json 中testtarget 使用angular-devkit/build-angular:karmabuildertest: { builder: angular-devkit/build-angular:karma, options: { polyfills: [zone.js, zone.js/testing], tsConfig: tsconfig.spec.json, assets: [src/favicon.ico, src/assets], styles: [src/styles.css], scripts: [] } }测试入口由tsconfig.spec.json与test.ts约定polyfills额外引入zone.js/testing以支持异步测试fakeAsync 等Karma builder 的实现位于仓库 packages/angular_devkit/build_angular/plugins/karma.ts 与src/builders/karma目录其职责是搭建 Webpack 测试编译管线并将结果上报给 Karma runner默认ng test进入 watch 模式持续监听测试变更CI 场景常用ng test --watchfalse --browsersChromeHeadless单次运行。该项目的组件规格文件 src/app/app.component.spec.ts 即采用 Jasmine 语法编写与types/jasmine依赖package.json 中~4.3.0对应。七、端到端测试ng e2eREADME 特别强调ng e2e需要一个额外安装的端到端测试框架才能运行CLI 本身不捆绑 e2e 实现。这与仓库模板 packages/schematics/angular/workspace/files/README.md.template 中Angular CLI does not come with an end-to-end testing framework by default. You can choose one that suits your needs.的表述一致——Angular CLI 的设计是保持核心精简把 e2e 方案的选择权交给开发者Protractor 时代之后社区通常选用 Playwright、Cypress 等并配合ng e2e的自定义 builder 接入。从本项目 angular.json 可以看出fixture 并未预置e2etarget这正是需自行添加框架在配置层面的直接体现。八、进一步帮助ng help与仓库内文档README 最后建议通过ng help获取 Angular CLI 的全部命令帮助。对应地本仓库根目录 README.md 对 Angular CLI 的整体定位、docs/README.md 聚合了设计文档与规范说明如 docs/specifications/update.md 讲解版本升级机制、docs/design/ngConfig.md 讲解 workspace 配置设计可作为从会跑命令走向理解原理的进阶阅读路线。九、总结一份 README 背后的完整工程视图以这份 README.md 为索引我们实际上梳理出了一个标准 Angular CLI SSRWebpack 方案工程的全貌开发体验ng serve提供客户端热重载dev:ssr提供 SSR 模式下的同步重载生产效率ng generate依托 packages/schematics/angular 的 schematics 体系批量生成规范代码交付质量ng build通过 budgets 约束包体积test/e2e双轨保障质量SSR 落地build:ssrserve:ssrprerender构成服务端渲染 预渲染的完整部署矩阵核心引擎由 packages/angular/ssr 提供工程可迁移性该目录同时是仓库 e2e 测试的 fixture见 tests/e2e/tests/update/update-application-builder.ts说明这套配置经得起旧版生成 → 新版升级 → 重新构建的真实场景验证。对开发者而言把这份 README 的每个命令与其对应的 builder、schematic、配置文件一一对上号就掌握了 Angular CLI 项目的完整操作面与扩展入口后续无论是替换 e2e 框架、调整构建预算还是接入 SSR 路由都能从 angular.json 出发快速定位到正确的配置位置。【免费下载链接】angular-cliCLI tool for Angular项目地址: https://gitcode.com/gh_mirrors/an/angular-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考