Angular 从 Google 内部和更广泛的开源社区都收到了大量的特性请求。与此同时，我们的项目列表包含大量维护任务、代码重构、潜在的性能提升等等。我们汇集了来自来自开发者关系部门、产品管理部门和工程部门的代表，以确定此列表的优先顺序。当新项目进入队列时，我们会根据其它项目的相对优先级定期对它们进行排位。当工作完成后，项目就会在队列中向上移动。
下面这些项目并没有关联到特定的 Angular 版本。我们会在完成时发布它们，它们会根据我们的发布计划，并遵循语义化版本规范，变成特定版本的一部分。比如，当完成各种特性后会在下一个次要版本中发布，如果包含重大变更，则会到下一个主版本中发布。
在使 Angular 更简单的过程中，我们正在努力引入 API，允许开发人员初始化应用程序、实例化组件，以及在不使用 NgModules 的情况下使用路由器。Angular v14 引入了独立组件、指令和管道的 API 的开发人员预览。在接下来的几个季度，我们将收集开发人员的反馈，并完成使 API 稳定的项目。作为下一步，我们将努力改进用例，例如 TestBed 、Angular 元素等。
Aurora和 Angular 团队正在努力实现旨在改进Core Web Vitals的镜像指令。目前，该项目处于原型设计阶段，团队正在与合作伙伴验证镜像指令。
我们进行了 40 次系列采访，以了解社区对微前端架构的需求。我们随后进行了更广泛的社区调查。下一步，我们将公开分享对结果的分析。
通过加快构建时间研究现代包来改善开发体验。作为使用esbuild和其他开源解决方案的项目试验的一部分，将它们与 Angular CLI 中的最先进工具进行比较，并报告结果。在 Angular v14 中，我们发布了对 esbuild 的实验性支持。接下来，团队将专注于验证新原型以及实现 watch 和 Sass 支持。
Web 生态系统在不断发展，我们希望在 Angular 中反映最新的现代标准。在这个项目中，我们旨在提供有关在 Angular 中使用现代 CSS 特性的指南，以确保开发人员遵循布局、样式等方面的最佳实践。
一个长期存在的特性请求是添加向宿主元素添加指令的能力。该特性允许开发人员在不使用继承的情况下使用其他行为来增强自己的组件。该项目需要在 API 的定义、语义和实现方面付出巨大的努力。
Angular 和 Chrome DevTools 正在共同努力，为错误消息启用更具可读性的堆栈跟踪。
我们正在开发新的 CDK 原语，以促进根据 WAI-ARIA 设计模式为Listbox和Combobox创建自定义组件。作为该项目的一部分，Angular v14 引入了稳定的菜单和对话框原语。
MDC Web是由 Google Material Design 团队创建的一个库，它为构建 Material Design 组件提供了可重用的原语。Angular 团队正在将这些原语合并到 Angular Material 中。使用 MDC Web 可以使 Angular Material 与 Material Design 规范更紧密地保持一致，扩展无障碍性，提高组件质量，并提高我们团队的速度。
我们正在根据 WCAG 等无障碍性标准评估 Angular Material 中的组件，并努力解决此过程中出现的任何问题。
确保所有现有的文档都适合一组一致的内容类型。将过度使用教程风格的文档更新为独立的主题。我们希望确保主教程之外的内容是自给自足的，而不与一系列指南紧密耦合。在 2022 年第二季度，我们重构了模板内容。下一步是为组件和依赖注入引入更好的结构。
作为这项工作的一部分，我们将使用服务器端渲染、不同的方法和 Angular 的机会来探索水化的问题空间。作为这个项目的结果，我们将验证所做的工作以及行动计划。
我们有一套针对每一次代码更改都要运行的基准测试，以确保 Angular 符合我们的性能标准。为确保框架的运行时在代码更改后不会退化，我们需要改进仪表板所使用的一些现有基础设施。
我们将设计并实施一项计划，使 Zone.js 在 Angular 应用程序中成为可选项。这样，我们简化了框架，改进了调试，并减少了应用程序包的大小。此外，这让我们可以利用当前 Zone.js 不支持的内置 async/await 语法。
将 Angular 编译器作为 TypeScript 编译器的插件分发将大大提高开发人员的构建性能并降低维护成本。
Web 应用程序的一个常见问题是它们的初始加载时间很慢。改进它的一种方法是在组件级别应用更精细的代码拆分。为了鼓励这种实践，我们将致力于开发更符合人体工程学的代码拆分 API。
我们希望确保 Angular 开发人员正在利用 RxJS 的最新特性，并平滑过渡到框架的下一个主要版本。为此，我们将探索并记录 v7 及更高版本的 RxJS 中更改的范围，并计划更新策略。
为了改进 Angular 和 Angular DevTools 的调试工具，我们将使用提供依赖注入运行时访问的 API。作为项目的一部分，我们将公开调试方法，这些方法允许我们探索注入器层次结构以及跨关联提供程序的依赖项。
作为本项目的一部分，我们想实现对 Angular CDK 拖放的混合方向支持。这是存储库中要求最高的特性之一。
为了改进 Angular 组件的封装，我们启用了绑定到组件实例的受保护成员的功能。这样，你将不再需要将字段或方法公开为 public 来在模板中使用它。
开发并发布有关变更检测的深入指南。开发用于 Angular 应用程序性能分析的内容。介绍变更检测如何与 Zone.js 交互，并解释它何时被触发、如何分析其持续时间以及性能优化的常见实践。
在 2021 年第四季度，我们设计了一个为表单引入严格类型的解决方案，并在 2022 年第一季度，我们完成了相应的评论请求。目前，我们正在实施具有自动迁移步骤的推出策略，这将支持对现有项目的改进。我们会首先在 Google 的 2500 多个项目中测试此解决方案，以确保为外部社区提供顺畅的迁移路径。
在我们所有内部工具向 Ivy 的转换完成后，我们将移除旧的 View Engine，以减少 Angular 的概念开销、获得更小的包大小、更低的维护成本和更低的代码库复杂度。
为了简化 Angular 心智模型和学习旅程，我们将努力使 NgModules 成为可选。这项工作允许开发人员开发独立组件并实现另一种 API 来声明组件的编译范围。我们通过在RFC中捕获的高级设计讨论来启动这个项目。
我们将努力寻找一种方法，以具有最小向后不兼容影响的方式对响应式表单实施更严格的类型检查。通过这种方式，我们可以让开发人员在开发期间发现更多问题，启用更好的文本编辑器和 IDE 支持，并改进响应式表单的类型检查。
为了改进 Angular DevTools 与框架的集成，我们正在努力将代码库移至angular/angular这个单一仓库。这包括将 Angular DevTools 转换为 Bazel，并将其集成到现有流程和 CI 管道中。
将 Angular 编译器的诊断扩展到类型检查之外。引入其他正确性和一致性检查，以进一步保证正确性和最佳实践。
为确保我们提供面向未来的 e2e 测试策略，我们希望评估 Protractor 的状态、社区创新、e2e 最佳实践，并探索新的机会。作为努力的第一步，我们共享了一个RFC，并与合作伙伴合作，以确保 Angular CLI 与用于 e2e 测试的最先进工具之间的顺利集成。下一步，我们需要最终确定建议并为过渡编译资源列表。
在 2020 年初，我们共享了一个用于 Ivy 库分发的RFC。在来自社区的宝贵反馈之后，我们开发了该项目的设计。我们现在正在投资开发 Ivy 库发行版，包括更新库包格式以使用 Ivy 编译、取消阻止 View Engine 库格式的弃用以及ngcc。
为了缩短测试时间并在测试之间创建更好的隔离，我们希望将TestBed更改为在每次测试运行后自动清理和拆除测试环境。
Internet Explorer 11 (IE11) 一直在阻止 Angular 利用 Web 平台的一些现代特性。作为本项目的一部分，我们将弃用并删除 IE11 支持，为常绿浏览器提供的现代特性打开道路。我们运行了一个RFC来收集社区的反馈，并决定接下来的步骤。
支持现代浏览器让我们可以利用 JavaScript 更紧凑、更具表现力和高性能的新语法。作为本项目的一部分，我们将调查哪些障碍是为了推进这项工作，并采取措施启用它。
我们正在开发 Angular 的开发工具，它提供用于调试和性能分析的实用程序。该项目旨在帮助开发人员了解 Angular 应用程序中的组件结构和变更检测。
我们希望在 Angular 的多个 GitHub 存储库（angular/angular 、 angular/angular-cli和angular/components）之间整合发布管理工具。这项工作让我们可以复用基础设施，统一和简化流程，并提高我们发布流程的可靠性。
我们希望统一跨 Angular 存储库（angular/angular 、 angular/components 、 angular/angular-cli）的提交消息要求和一致性，以便为我们的开发过程带来一致性并复用基础设施工具。
该项目的目标是通过将语言服务转换为 Ivy 来改善体验并消除遗留依赖。今天，语言服务仍然使用 View Engine 编译器和类型检查，即使对于 Ivy 应用程序也是如此。我们希望使用 Ivy 模板解析器和改进的 Angular 语言服务类型检查来匹配应用程序行为。此次迁移也是朝着移除 View Engine 的方向迈出的一步，这将简化 Angular，减少 npm 包大小，并提高框架的可维护性。
我们与 Google 的安全团队合作，增加了对新 Trusted Types API 的支持。此 Web 平台 API 可帮助开发人员构建更安全的 Web 应用程序。
作为 v11 版本的一部分，我们在 Angular CLI 中引入了 webpack 5 的可选预览。为确保稳定性，我们将继续迭代实现以实现构建速度和包大小改进。
加载外部样式表是一个阻塞型操作，这意味着浏览器在加载所有引用的 CSS 之前无法开始渲染你的应用程序。在页面的标题中拥有阻塞渲染的资源会显著影响其加载性能，比如，它的首次内容绘制。为了使应用程序更快，我们一直在与 Google Chrome 团队合作内联关键 CSS 并异步加载其余样式。
错误消息通常会带来有限的行动指南来帮助开发人员解决它们。我们一直致力于通过添加相关代码、开发指南和其他资料来使错误消息更易于发现，以确保更顺畅的调试体验。
我们将重新定义用户学习旅程并刷新介绍性文档。我们将清楚地说明 Angular 的好处，如何探索其功能并提供指导，以便开发人员可以在尽可能短的时间内精通该框架。
Angular CDK 在 Angular 9 中引入了组件测试工具的概念。测试工具能让组件作者创建支持的 API 来测试组件交互。我们将继续改进此测试工具基础架构，并阐明有关使用这些测试工具的最佳实践。我们还在努力推动 Google 内部更多地采用测试工具。
内容投影是一个核心的 Angular 概念，但在文档中却没有足够的篇幅来讲它。作为该项目的一部分，我们希望确定内容投影的核心用例和概念并记录它们。
随着 TSLint 的弃用，我们将转向 ESLint。作为该过程的一部分，我们将努力确保与我们当前推荐的 TSLint 配置向后兼容，为现有 Angular 应用程序实施迁移策略，并将新工具引入 Angular CLI 工具链。
我们正努力将高达 50% 的工程能力投入到分类问题和 PR 上，直到我们清楚了解更广泛的社区需求。之后，我们将投入多达 20% 的工程能力，以便及时跟进新提交的要求。