| RFC-0176：禁止在 Fuchsia 源代码树中使用新的 Dart 程序 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 向 Fuchsia 源代码树添加新的 Dart 程序需要获得豁免。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2022-06-07 |
| 审核日期（年-月-日） | 2022-07-06 |
摘要
我们建议为 Fuchsia 源代码树中的 Dart 程序创建许可清单。
初始许可名单将包含所有此类现有 Dart 程序。在 Fuchsia 源代码树中编写新的 Dart 程序需要获得豁免。
在树外“产品”环境中编写以 Fuchsia 为目标的新 Dart 程序将继续获得全面支持。
定义
- Dart 程序 ：对任何 Dart 程序代码（库或完整二进制文件）的引用，旨在在宿主机或 Fuchsia 目标上运行。
- 树内：Fuchsia 源代码树内的程序代码，包括“//src/experiences”的内容和“//vendor/”的内容。
- 树外 (OOT) ：Fuchsia 源代码树之外以 Fuchsia 为目标的程序代码。
- 全局集成 (GI) ：定义 Fuchsia 源代码树中各个项目的当前状态的中央账本。此账本通常由称为“rollers”的自动化流程更新。
设计初衷
Fuchsia 上的 Flutter 团队希望从树内环境中移除对 Dart 编程语言的支持。
创建许可名单将有助于 Fuchsia 上的 Flutter 团队跟踪和限制 Dart 的新用途，并规划其最终迁移。我们将在未来的 RFC 中介绍迁移现有 Dart 程序的具体计划。
该团队希望将 Dart 支持移出树外的原因有以下几个：
- 减轻 Fuchsia 平台的维护负担 ：移除树内 Dart 支持将使 Fuchsia 平台能够更快地开发。当所有产品都在树外开发和组装时，Fuchsia 平台将不再需要将 Dart 和 Flutter 运行时纳入 GI。目前，这些纳入 GI 的内容是维护负担的主要来源。 “维护负担”包括对 Flutter->GI rollers、3p Dart 软件包的 third_party/dart->GI rollers 以及树内使用 Dart 分析工具的支持。
- 提高产品/平台分离度 ：即使有许可名单，Fuchsia 产品所有者仍然可以通过树外产品组装将 Dart 和 Flutter 纳入其产品。树外产品组装将成为产品所有者将 Dart 或 Flutter 纳入其产品的唯一机制。 这将清楚地将 Dart 和 Flutter 运行时划入平台-产品边界的产品端。
- 分离 Fuchsia 平台和树外运行时的验证 ：目前，树内 Dart 的大部分用途都是集成测试，旨在验证 Dart 和 Flutter 运行时的运行情况。例如，在 UI、FIDL 和诊断网域中针对 Dart 运行时运行的集成测试。这些测试说明了目前如何不强制执行产品/平台分离。 它们将平台本身视为要运行的产品，然后尝试在同一测试中同时验证平台的合约和（产品）运行时。
- 减少对 Fuchsia SDK 中下游项目的依赖 ：Fuchsia SDK 发布了一组 Dart 库（例如 SL4F），这些库旨在针对特定版本的 Dart 和 Flutter 运行时运行。验证这些库的运行情况需要使用 roller 更新 GI 中的 Dart 和 Flutter 运行时，然后在树内编写基于 Dart 的测试。 最终，这会导致与上述相同的可维护性和产品/平台分离问题。
- 鼓励收敛到基于 ffx 的工作流：禁止将 Dart 用于新的主机工具将成为创建更多 基于 ffx 的工作流的强制功能。
- Dart 语言政策：此提案实际上是 现有语言政策的更严格版本，即平台组件不应使用 Dart 编写，现在已扩展到平台测试和主机工具。
利益相关方
辅导员：
abarth@google.com
审核人：
- akbiggs@google.com（Fuchsia 上的 Flutter）
- fmeawad@google.com（性能）
- sanjayc@google.com（工作站）
- yuanzhi@google.com (SL4F)
- shaibarack@google.com（技术债 WG）
咨询对象：
- chaselatta@google.com (OOT)
- jaeheon@google.com (UI)
- crjohns@google.com（诊断）
- yifeit@google.com (FIDL)
- dannyrosen@google.com（技术债 WG）
- mangini@google.com（开发者关系）
共同化：
此 RFC 的初始共同化提案已与所有受影响的团队（在上面的“审核人”或“咨询对象”中列出）进行了单独对话。 然后，RFC 作者在“2022 Fuchsia SDK 峰会”期间举办了一个关于此 RFC 内容的研讨会。
设计
Fuchsia 上的 Flutter 团队将维护一个 Dart 程序列表，这些程序允许存在于树内 Fuchsia build 的 build 图中。此列表的初始内容将是树内所有现有的 Dart 程序。
在设计政策和强制执行机制时，我们尝试牢记以下原则：
- 增量性：虽然 Fuchsia 上的 Flutter 团队希望最终 移除树内 Dart 程序，但必须逐步完成此迁移，以避免对树内现有 Dart 用户产生负面影响。换句话说，我们不打算在找到合适的替代方案之前删除任何树内承重 Dart 程序。由于无法立即迁移，我们必须先制定许可名单，然后才能开始迁移任何树内 Dart 程序。 这将减缓或停止添加新程序，而不会对现有程序产生负面影响。
- 包容性：即使树内 Dart 的使用量已经下降，并且 平台组件可能已经无法使用 Dart 编写，但基于 Fuchsia 构建的产品将继续扩大 Dart 的使用量。我们必须保留产品所有者继续在树外使用 Dart 来开发自己的组件和主机工具的能力。因此，许可名单不得应用于任何树外 Dart 程序。
实现
我们将根据树内现有 Dart 程序列表在 fuchsia.git 中生成初始许可名单。根据增量性设计原则，我们将在许可名单中添加一个用于性能测试的通配符条目；此通配符条目将允许在“//src/tests/end_to_end/perf”内添加新的性能测试。
生成初始列表后，我们将实现一种机制，用于在构建时间强制执行许可名单。此实现将使用 GN 可见性来限制向 build 添加新的 dart_library、flutter_library、dart_test、flutter_test 和 dart_tool 目标。这样，它的行为将与驱动程序共享库许可名单等许可名单类似。
在此之后，如果 build 树中存在 Dart 程序但未包含在许可名单中，树内 GN build 将发出 build 时错误。 我们不会通过许可名单机制限制现有 Dart 程序的扩展，但我们会在设计和代码审核中阻止这种做法。
性能
这纯粹是政策和构建系统变更；我们预计不会对性能产生任何影响。
向后兼容性
许可名单的初始内容将包含树内所有现有的 Dart 程序，因此强制执行将完全向后兼容。
安全注意事项
这纯粹是政策和 build 系统变更；我们预计不会对安全性产生任何影响。
隐私注意事项
这纯粹是政策和 build 系统变更；我们预计不会对隐私产生任何影响。
测试
我们将许可名单实现为构建时检查，这意味着主要测试是 Fuchsia 源代码树是否继续正确构建。如果树继续正确构建，则表示所有 Dart 程序都符合许可名单的限制。
文档
此 RFC 可作为我们创建许可名单意图的文档。
我们需要为开发者更新一些文档：
- 语言政策：更新 fuchsia.dev 语言政策，以反映这些 政策变更。
- 教程：向 fuchsia.dev 文档中添加警告和许可名单说明，其中涵盖了编写 Dart 程序。
缺点、替代方案和未知因素
此提案的主要缺点是，在树内编写新的 Dart 程序将变得困难。 Fuchsia 开发者在编写主机工具时通常会使用 Dart，因为 Dart 过去可用且易于使用。
如果没有 Dart 可用选项，编写与 Fuchsia 设备互动的主机工具的唯一可行替代方案是实现 ffx 插件。 我们希望开发者能够接受这一点，因为 ffx 已经是使用 Fuchsia SDK 编写此类主机工具的理想途径。
此提案的一个主要未知因素是，如何在严格在树外构建 Dart 程序的世界中适应 Dart 与 Fuchsia 平台的深度集成（FIDL 绑定、一致性测试）。 目前，我们也不知道如何针对 Fuchsia SDK 版本协调树外 Dart 库的版本控制。Fuchsia 上的 Flutter 团队打算在后续 RFC 中解决这些未知因素。
在先技术和参考文档
现有的 Fuchsia Dart 语言政策：语言政策
此 RFC 提出了与驱动程序 共享库许可名单类似的基于许可名单的强制执行机制：驱动程序共享库许可名单 RFC