| 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 源代码树中各个项目的当前状态的中央账本。此账本通常由称为“滚动器”的自动化流程更新。
设计初衷
Fuchsia 上的 Flutter 团队希望从树内环境中移除对 Dart 编程语言的支持。
创建许可名单有助于 Fuchsia 上的 Flutter 团队跟踪和限制 Dart 的新用法，并规划最终迁移。我们将在未来的 RFC 中介绍迁移现有 Dart 程序的具体方案。
该团队希望将 Dart 支持移至树外的原因有以下几个：
- 减轻 Fuchsia 平台维护负担：移除树内 Dart 支持将有助于 Fuchsia 平台更快地开发。当所有产品都在树外开发和组装时，Fuchsia 平台将不再需要将 Dart 和 Flutter 运行时纳入 GI。这些纳入 GI 的卷如今是维护负担的一大来源。“维护负担”包括对以下方面的支持：Flutter->GI 滚动、第三方/Dart->GI 滚动（针对第三方 Dart 软件包）以及 Dart 分析工具的树内使用。
- 提高产品/平台分离度：即使有许可名单，Fuchsia 产品所有者仍然可以通过树外产品组装自由地将 Dart 和 Flutter 纳入其产品中。树外产品组装将成为产品所有者将 Dart 或 Flutter 纳入其产品的唯一机制。这将清楚地将 Dart 和 Flutter 运行时划定到平台-产品边界的产品侧。
- 单独验证 Fuchsia 平台和树外运行时：目前，树内的大部分 Dart 用法都是以集成测试的形式出现，旨在验证 Dart 和 Flutter 运行时的运行情况。示例包括在界面、FIDL 和诊断网域中针对 Dart 运行时运行的集成测试。这些测试示例表明，目前尚未强制执行产品/平台分离。他们将平台本身视为要运行的产品，然后尝试在同一测试中同时验证平台的合约和（产品）运行时。
- 减少对 Fuchsia SDK 中下游项目的依赖：Fuchsia 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（不在办公室）
- jaeheon@google.com（界面）
- crjohns@google.com（诊断）
- yifeit@google.com (FIDL)
- dannyrosen@google.com（技术债工作组）
- mangini@google.com（开发者关系）
共同化：
此 RFC 的初始社交化提案已与上述“审核者”或“咨询对象”中列出的所有受影响团队进行了单独对话。随后，RFC 作者在“2022 年 Fuchsia SDK 峰会”期间举办了一场关于此 RFC 内容的研讨会。
设计
Flutter on Fuchsia 团队将维护一个 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”中添加新的性能测试。
生成初始列表后，我们将实现用于在 build 时强制执行许可名单的机制。此实现将使用 GN 可见性来限制向 build 中添加新的 dart_library、flutter_library、dart_test、flutter_test 和 dart_tool 目标。这样一来，它的行为将与驱动程序共享库许可名单等许可名单类似。
在此之后，如果 build 树中存在 Dart 程序但未包含在许可名单中，树内 GN build 将会发出 build 时错误。我们不会通过许可名单机制来限制现有 Dart 程序的扩展，但会在设计和代码审核中不鼓励这样做。
性能
这纯粹是政策和 build 系统方面的变更；我们预计不会对性能产生影响。
向后兼容性
许可名单的初始内容将包含树中的所有现有 Dart 程序，因此强制执行将完全向后兼容。
安全注意事项
这纯粹是政策和 build 系统方面的变更；我们预计不会对安全性造成影响。
隐私注意事项
这纯粹是政策和 build-system 变更；我们预计不会对隐私权造成影响。
测试
我们将把许可名单实现为构建时检查，这意味着主要测试是 Fuchsia 源代码树继续正确构建。如果树继续正确构建，则表示所有 Dart 程序都符合许可名单的限制。
文档
此 RFC 记录了我们创建许可名单的意图。
我们需要更新一些面向开发者的文档：
- 语言政策：更新 fuchsia.dev 语言政策，以反映这些政策变更。
- 教程：向涵盖编写 Dart 程序的 fuchsia.dev 文档添加警告和许可名单说明。
缺点、替代方案和未知因素
此提案的主要缺点是，在源代码树中编写新的 Dart 程序会变得困难。Fuchsia 开发者在编写主机工具时通常会选择 Dart，因为该语言之前一直可用且易于使用。
在没有 Dart 可用的情况下，编写与 Fuchsia 设备互动的宿主工具的唯一可行替代方案是实现 ffx 插件。我们希望开发者能够接受这一点，因为 ffx 已经是使用 Fuchsia SDK 编写此类主机工具的推荐途径。
此提案的一个主要未知因素是，在 Dart 程序严格进行树外构建的世界中，如何适应 Dart 与 Fuchsia 平台的深度集成（FIDL 绑定、一致性测试）。我们目前也不知道如何协调树外 Dart 库的版本控制与 Fuchsia SDK 版本。flutter-on-fuchsia 团队打算在后续 RFC 中解决这些未知问题。
在先技术和参考资料
适用于 Dart 的现有 Fuchsia 语言政策：语言政策
此 RFC 提出了一种与驱动程序共享库许可名单类似的基于许可名单的强制执行机制：驱动程序共享库许可名单 RFC