Angular 路线图

Signal 表单

在 Angular v21 中，我们推出了 Signal 表单（Signal Forms）的实验版本。这种新方法允许开发者使用 Signal 来管理表单状态，从而提供更符合人体工程学的表单创建体验。接下来，我们的计划包括将 Signal 表单推向稳定版，并增强与响应式表单（Reactive Forms）的互操作性——使团队能够按照自己的节奏逐步迁移大型表单。

改进 HMR（热模块替换）

我们正致力于通过启用热模块替换来缩短编辑/刷新周期。

在 Angular v19 中，我们提供了对 CSS 和模板 HMR 的初始支持，并在 v20 中将模板 HMR 升级为稳定版。我们将继续收集反馈，以确保在将此项目标记为完成之前，能够切实解决开发者的需求。

交付 Angular Signals

该项目通过引入 Signals 作为响应式基元，重新构想了 Angular 的响应性模型。最初的规划带来了数百次讨论、与开发者的交流、反馈会议、用户体验研究以及一系列收到超过 1,000 条评论的 RFC。

在 Angular v20 中，我们已将所有基础响应式基元推向稳定版，包括 signal、effect、linkedSignal、基于 signal 的查询以及 inputs。

支持二维拖放

作为该项目的一部分，我们为 Angular CDK 拖放实现了混合方向支持。这是该仓库中最受期待的功能之一。

配合 SSR 和预渲染的事件回放

在 v18 中，我们引入了在使用服务端渲染或预渲染时的事件回放功能。此功能依赖于在 Google.com 上运行的事件分发基元（此前称为 jsaction）。

在 Angular v19 中，我们将事件回放升级为稳定版，并默认对所有新项目启用。

扩展 Angular Material 的可定制性

为了更好地定制我们的 Angular Material 组件并启用 Material 3 功能，我们将与 Google 的 Material Design 团队合作，定义基于 token 的主题 API。

在 v17.2 中，我们分享了对 Angular Material 3 的实验性支持，并在 v18 中将其升级为稳定版。

引入延迟加载

在 v17 中，我们发布了开发者预览版的延迟加载视图（deferrable views），它为延迟代码加载提供了一个符合人体工程学的 API。在 v18 中，我们为库开发者启用了延迟加载视图，并将该 API 升级为稳定版。

自动将现有的混合渲染项目过渡到 esbuild 和 vite

在 v17 中，我们发布了基于 vite 和 esbuild 的应用构建器，并对新项目默认启用。对于使用混合渲染的项目，它将构建时间缩短了多达 87%。作为 v18 的一部分，我们提供了 schematics 和指南，用于将现有的使用混合渲染的项目迁移到新的构建管道。

使 Angular.dev 成为 Angular 开发者的官方家园

Angular.dev 是 Angular 开发的新网站、域名和家园。新网站包含更新的文档、教程和指南，将帮助开发者利用 Angular 的最新特性进行构建。

引入内置控制流

在 v17 中，我们发布了新内置控制流的开发者预览版。它带来了显著的性能提升，并为模板编写提供了更好的易用性。我们还提供了针对现有 *ngIf、*ngFor 和 *ngSwitch 的迁移工具，你可以运行它来将项目过渡到新的实现。自 v18 起，内置控制流现已稳定。

研究现代打包工具

在 Angular v16 中，我们发布了基于 esbuild 的构建器的开发者预览版，并支持 ng build 和 ng serve。ng serve 开发服务器使用 Vite 以及通过 esbuild 和 Angular 编译器进行的多文件编译。在 v17 中，我们将该构建工具从开发者预览版升级为稳定版，并将其对新项目默认启用。

引入依赖注入调试 API

为了改进 Angular 和 Angular DevTools 的调试工具，我们将致力于开发提供对依赖注入运行时访问的 API。作为项目的一部分，我们将公开调试方法，以允许我们探索注入器层级结构以及跨其关联提供者的依赖关系。自 v17 起，我们推出了支持接入依赖注入生命周期的功能。我们还发布了注入器树的可视化以及对每个独立节点内声明的提供者的检查功能。

改进独立组件的文档和 schematics

我们发布了 ng new --standalone schematics 集合的开发者预览版，允许你创建无需 NgModule 的应用。在 v17 中，我们将新的应用编写格式切换为独立（standalone）API，并更改了文档以反映该推荐做法。此外，我们还提供了支持将现有应用更新为独立组件、指令和管道的 schematics。尽管 NgModule 在可预见的未来依然会存在，本着改进开发体验并受益于我们为其构建的新特性的初衷，我们建议你探索新 API 的优势。

非破坏性完全应用水合

在 v16 中，我们发布了非破坏性完全水合的开发者预览版，这允许 Angular 在服务端渲染的页面上重用现有的 DOM 节点，而不是从头开始重新创建应用。请参阅水合指南中的其他信息。

图片指令的改进

我们在 v15 中发布了稳定的 Angular 图片指令。我们引入了全新的填充（fill）模式功能，该功能使图片能够适应其父容器，而无需指定明确的尺寸。在过去的两个月里，Chrome Aurora 团队将该指令向后移植到了 v12 及更高版本。

文档重构

确保所有现有文档符合一致的内容类型。将过多使用的教程风格文档更新为独立的主题。我们希望确保主教程之外的内容是自成体系的，而不是与一系列指南紧密耦合。在 2022 年第二季度，我们重构了模板内容和依赖注入。在 2023 年第一季度，我们改进了 HTTP 指南，并以此将文档重构项目暂时搁置。

提升图片性能

Aurora 和 Angular 团队正致力于实现旨在改善 Core Web Vitals 的图片指令。我们在 v15 中发布了该图片指令的稳定版本。

现代 CSS

Web 生态系统在不断演进，我们希望在 Angular 中体现最新的现代标准。在本项目中，我们的目标是提供在 Angular 中使用现代 CSS 特性的指南，以确保开发者遵循布局、样式等方面的最佳实践。我们分享了官方的布局指南，并作为该倡议的一部分，停止了 flex 布局的发布。

支持在宿主元素上添加指令

一个长期存在的功能请求是能够在宿主元素（host elements）上添加指令。该功能让开发者无需使用继承即可为其组件增加额外的行为。在 v15 中，我们推出了指令组合 API（directive composition API），支持通过指令增强宿主元素。

更好的堆栈追踪

Angular 和 Chrome DevTools 正在展开合作，使错误信息的堆栈追踪更具可读性。在 v15 中，我们发布了改进的相关和链接堆栈追踪。作为一项较低优先级的计划，我们将探索如何通过为模板提供更准确的调用帧名称来使堆栈追踪更加友好。

通过集成 MDC Web 增强 Angular Material 组件

MDC Web 是由 Google Material Design 团队创建的库，提供了用于构建 Material Design 组件的可重用基元。Angular 团队正在将这些基元整合到 Angular Material 中。使用 MDC Web 可使 Angular Material 与 Material Design 规范更紧密地保持一致、扩展无障碍性、提升组件质量，并提高我们团队的开发效率。

实现可选 NgModule 的 API

在使 Angular 更加简单的过程中，我们正在致力于引入允许开发者在不使用 NgModule 的情况下初始化应用、实例化组件以及使用路由的 API。Angular v14 引入了适用于独立组件、指令和管道的 API 开发者预览版。在接下来的几个季度中，我们将收集开发者的反馈并最终完成该项目，使这些 API 走向稳定。下一步，我们将致力于改进诸如 TestBed、Angular elements 等用例。

允许在模板中绑定到受保护字段

为了改进 Angular 组件的封装性，我们启用了对组件实例受保护（protected）成员的绑定。这样，你无需再为了在模板中使用某个字段或方法而将其公开（public）。

发布高级概念指南

开发并发布关于变更检测的深入指南。开发用于 Angular 应用性能分析的内容。涵盖变更检测如何与 Zone.js 交互，并解释何时触发它、如何分析其持续时间，以及性能优化的常见做法。

为 @angular/forms 推出严格类型

在 2021 年第四季度，我们设计了为表单引入严格类型的解决方案，并在 2022 年第一季度结束了相应的征求意见（RFC）。目前，我们正在实施一项带有自动迁移步骤的推出策略，该步骤将对现有项目启用改进。我们首先在 Google 的 2500 多个项目中测试了该解决方案，以确保外部社区能拥有平滑的迁移路径。

移除遗留的 View Engine

在我们将所有内部工具完全过渡到 Ivy 之后，我们将移除遗留的 View Engine，以减少 Angular 的概念开销、缩减包体大小、降低维护成本和减小代码库复杂度。

通过可选 NgModule 简化 Angular 心智模型

为了简化 Angular 的心智模型和学习旅程，我们将致力于使 NgModule 成为可选。这项工作能让开发者开发独立组件，并实现用于声明组件编译范围的替代 API。我们以高层设计讨论启动了该项目，并将其记录在了一份 RFC 中。

为 @angular/forms 设计严格类型

我们将努力寻找一种为响应式表单实现更严格类型检查的方法，并尽量减少向后不兼容的影响。这样一来，我们可以让开发者在开发期间捕获更多问题、提供更好的文本编辑器和 IDE 支持，并改进对响应式表单的类型检查。

改进 Angular DevTools 与框架的集成

为了改进 Angular DevTools 与框架的集成，我们正在努力将代码库迁移到 angular/angular 单一代码仓库（monorepository）中。这包括将 Angular DevTools 过渡到 Bazel 并将其集成到现有流程和 CI 管道中。

推出高级编译器诊断

将 Angular 编译器的诊断扩展到类型检查之外。引入其他正确性和符合性检查，以进一步保证正确性和最佳实践。

更新我们的端到端（e2e）测试策略

为了确保我们提供面向未来的端到端（e2e）测试策略，我们希望评估 Protractor 的状态、社区创新、e2e 最佳实践，并探索新的机遇。作为这项工作的第一步，我们分享了一份 RFC，并与合作伙伴合作，以确保 Angular CLI 与尖端 e2e 测试工具之间的平滑集成。下一步，我们需要确定最终推荐方案，并汇编一份用于过渡的资源列表。

Angular 库使用 Ivy

在 2020 年早些时候，我们分享了一份关于 Ivy 库分发的 RFC。在获得社区宝贵的反馈后，我们开发了该项目的设计方案。我们目前正在对 Ivy 库分发的开发进行投入，包括更新库的包格式以使用 Ivy 编译、解除对 View Engine 库格式的废弃限制，以及 ngcc。

通过自动销毁测试环境来改善测试时间和调试

为了缩短测试时间并在测试之间创建更好的隔离，我们希望更改 TestBed，使其在每次测试运行后自动清理和销毁测试环境。

废弃并移除对 IE11 的支持

Internet Explorer 11 (IE11) 一直在阻碍 Angular 利用 Web 平台的一些现代功能。作为该项目的一部分，我们将废弃并移除对 IE11 的支持，从而为常青浏览器（evergreen browsers）提供的现代功能铺平道路。我们运行了一份 RFC 来收集社区的反馈，并决定下一步的发展方向。

将 ES2017+ 作为默认输出语言

支持现代浏览器使我们能够利用 JavaScript 更紧凑、更具表现力且性能更高的全新语法。作为该项目的一部分，我们将调查推进这项工作的阻碍是什么，并采取步骤启用它。

通过 Angular DevTools 加速调试和性能分析

我们正在开发 Angular 开发工具，提供用于调试和性能分析的实用程序。该项目旨在帮助开发者理解 Angular 应用中的组件结构和变更检测。

通过统一 Angular 版本控制和分支简化发布流程

我们希望整合 Angular 的多个 GitHub 仓库（angular/angular、angular/angular-cli 和 angular/components）之间的发布管理工具。这项工作使我们能够重用基础设施、统一并简化流程，并提高发布流程的可靠性。

通过提交信息标准化提高开发者的一致性

我们希望统一 Angular 各个仓库（angular/angular、angular/components 和 angular/angular-cli）的提交信息要求和合规性，从而为我们的开发过程带来一致性并重用基础设施工具。

将 Angular 语言服务过渡到 Ivy

该项目的目标是通过将语言服务过渡到 Ivy 来改善体验并消除遗留依赖。如今，即使对于 Ivy 应用，语言服务仍然在使用 View Engine 编译器和类型检查。我们希望为 Angular 语言服务采用 Ivy 模板解析器和改进的类型检查，以匹配应用的行为。此次迁移也是朝着解除 View Engine 移除限制迈出的一步，这将简化 Angular、减小 npm 包大小并提高框架的可维护性。

通过 Angular 中的原生可信类型（Trusted Types）提高安全性

在与 Google 安全团队的合作下，我们正在添加对全新可信类型（Trusted Types）API 的支持。这一 Web 平台 API 有助于开发者构建更安全的 Web 应用。

利用 Angular CLI webpack 5 优化构建速度和包体大小

作为 v11 版本发布的一部分，我们在 Angular CLI 中引入了 webpack 5 的选择性加入（opt-in）预览。为了确保稳定性，我们将继续对实现进行迭代，以改进构建速度和减小包体大小。

在 Universal 应用中内联关键样式以实现更快的应用

加载外部样式表是一项阻塞操作，这意味着在加载完所有引用的 CSS 之前，浏览器无法开始渲染你的应用。在页面头部包含阻塞渲染的资源会显著影响其加载性能，例如首次内容绘制（first contentful paint）。为了让应用更快，我们一直与 Google Chrome 团队合作，内联关键 CSS 并异步加载其余样式。

通过更佳的 Angular 错误信息改善调试体验

错误信息通常能提供的可操作信息有限，无法很好地帮助开发者解决问题。我们一直致力于通过添加关联错误码、开发指南和其他材料来让错误信息更易被发现，以确保更平滑的调试体验。

通过刷新引导文档来改进开发者上手体验

我们将重新定义用户的学习旅程并刷新引导文档。我们将明确阐述 Angular 的优势、如何探索其功能，并提供指导，以便开发者能在尽可能短的时间内熟练使用该框架。

扩展组件测试工具包（Harnesses）最佳实践

Angular CDK 在第 9 版中向 Angular 引入了组件测试工具包（test harnesses）的概念。测试工具包让组件作者能够创建受支持的 API 来测试组件交互。我们将继续改进该工具包基础设施，并澄清围绕使用工具包的最佳实践。我们还致力于推动在 Google 内部采用更多的工具包。

编写内容投影指南

内容投影是一个核心 Angular 概念，但在文档中并没有得到应有的重视。作为该项目的一部分，我们希望识别内容投影的核心用例和概念并对其进行记录。

迁移到 ESLint

随着 TSLint 的废弃，我们将转向 ESLint。作为该过程的一部分，我们将努力确保与当前推荐的 TSLint 配置的向后兼容性，实现现有 Angular 应用的迁移策略，并在 Angular CLI 工具链中引入新工具。

告别积压行动（也称为 Byelog 行动）

我们正在积极投入高达 50% 的工程能力来分类（triage）议题（issues）和 PR，直到我们对更广泛的社区需求有了清晰的理解。在此之后，我们将承诺投入高达 20% 的工程能力来及时跟进新的提交。