| 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 平台的开发更快。当所有产品都在树外进行开发和组装后，Fucsia 平台不再需要将 Dart 和 Flutter 运行时回滚到 GI 中。这些卷入 GI 是目前造成维护负担的一大原因。“维护负担”包括对 Flutter->GI 滚轮、第三方/dart->GI 滚轮（用于第三方 Dart 软件包）的支持，以及对 Dart 分析工具的树内使用。
- 加强产品与平台分离：即使设置了许可名单，Fuchsia 产品所有者仍然可以通过树外产品组装自由将 Dart 和 Flutter 整合到其产品中。树外产品组装将成为产品所有者可以将 Dart 或 Flutter 整合到其产品中的唯一机制。这样可将 Dart 和 Flutter 运行时明确划分到“平台-产品”边界的产品端。
- 单独验证 Fuchsia 平台和树外运行时：目前，在 Dart 树内使用的主要工具是集成测试，用于验证 Dart 和 Flutter 运行时的操作。示例包括针对 Dart 运行时运行的界面、FIDL 和诊断网域中的集成测试。这些测试说明了目前未强制执行产品/平台分离的情况。他们将平台本身视为要运行的产品，然后尝试在同一测试中同时验证平台的合同和（产品）运行时。
- 在 Fuchsia SDK 中减少对下游项目的依赖：Fucsia SDK 发布了一组 Dart 库（例如 SL4F），这些库旨在针对特定版本的 Dart 和 Flutter 运行时运行。验证这些库的操作需要使用滚轮在 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（技术债务小组）
咨询人员：
- chaselatta@google.com (OOT)
- jaeheon@google.com（界面）
- crjohns@google.com（诊断）
- yifeit@google.com (FIDL)
- dannyrisen@google.com（技术债务 WG）
- mangini@google.com（开发者关系）
社交：
此 RFC 的初始社交提案与上面“审核者”或“已咨询”中列出的所有受影响团队进行了单独对话。随后，RFC 作者在“2022 年 Fuchsia SDK 峰会”上举办了一场关于此 RFC 内容的研讨会。
设计
Fuchsia 上的 Flutter 团队将维护一份 Dart 程序列表，这些程序可存在于树内 Fuchsia build 的 build 图中。此列表的初始内容将是树中的所有现有 Dart 程序。
在设计政策和强制执行机制时，我们尽量遵循以下原则：
- 增量：虽然 Flutter-on-Fuchsia 团队希望最终移除树内 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 目标。这样一来，此许可名单的行为就类似于许可名单，例如驱动程序共享库许可名单。
在此之后，如果 Dart 程序存在于 build 树中，但未包含在许可名单中，则树内 GN build 将发出一个构建时错误。我们不会通过许可名单机制限制对现有 Dart 程序的扩展，但在设计和代码审核阶段不这样做。
性能
这仅仅是政策和构建系统方面的变更；我们预计性能不会受到任何影响。
向后兼容性
许可名单的初始内容将包含树内所有现有的 Dart 程序，因此强制执行将完全向后兼容。
安全注意事项
这纯粹是政策和构建系统方面的变更；我们预计不会对安全造成影响。
隐私注意事项
这仅属于政策和构建系统变更；我们预计隐私保护不会受到任何影响。
测试
我们将以构建时检查的形式实现该许可名单，这意味着主要测试是 Fuchsia 源代码树是否继续正确构建。如果树继续正确构建，这意味着所有 Dart 程序都在许可名单的限制范围内。
文档
本 RFC 旨在记录我们创建许可名单的意图。
我们需要为开发者更新一些文档：
- 语言政策：更新 fuchsia.dev 语言政策以反映这些政策变更。
- 教程：在介绍如何编写 Dart 程序的 fuchsia.dev 文档中添加警告和许可名单说明。
缺点、替代方案和未知情况
这种方案的一个主要缺点是，在树内编写新的 Dart 程序将非常困难。由于 Dart 的历史可用性和易用性，因此在编写主机工具时，Fuchsia 开发者通常会使用 Dart。
在没有 Dart 选项的情况下，若要编写与紫红色设备进行交互的主机工具，唯一可行的替代就是实现 ffx 插件。我们希望开发者能够接受，因为 ffx 已经成为使用 Fuchsia SDK 编写此类主机工具的良好途径。
此方案的一个主要未知是，Dart 程序完全是在树之外构建的，如何适应 Dart 与 Fuchsia 平台的深度集成（FIDL 绑定、一致性测试）。目前，我们也不知道如何根据 Fuchsia SDK 版本协调树外 Dart 库的版本控制。flutter-on-fuchsia 团队打算在后续 RFC 中解决这些未知问题。
早期技术和参考资料
Dart 的现有 Fuchsia 语言政策：语言政策
此 RFC 提出了一种与驾驶员共享库许可名单类似的基于许可名单的强制执行机制：驱动程序共享库许可名单 RFC