| 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 源代码树中各个项目的当前状态。此分类账通常由称为“滚动器”的自动化流程进行更新。
设计初衷
Flutter on Fuchsia 团队希望从树内环境中移除对 Dart 编程语言的支持。
创建许可名单有助于 Fuchsia 上的 Flutter 团队跟踪和限制 Dart 的新用法，并规划最终的迁移。我们将在未来的 RFC 中介绍迁移现有 Dart 程序的具体计划。
该团队希望将 Dart 支持移出树的原因有很多：
- 减少 Fuchsia 平台维护负担：移除树内 Dart 支持后，Fuchsia 平台的开发速度将加快。当所有产品都采用外部开发和组装方式时，Fuchsia 平台将不再需要将 Dart 和 Flutter 运行时引入 GI。目前，这些纳入 GI 的项目是造成维护负担的主要原因。“维护负担”包括对 Flutter->GI 滚筒的支持、适用于第三方 Dart 软件包的 third_party/dart->GI 滚筒，以及在树中使用 Dart 分析工具。
- 增强产品/平台分离：即使启用了许可名单，Fuchsia 产品所有者仍然可以通过树外产品组装自由地将 Dart 和 Flutter 纳入其产品。树外产品组装将成为产品所有者将 Dart 或 Flutter 纳入其产品的唯一机制。这将将 Dart 和 Flutter 运行时明确划分到平台-产品边界的“产品”一侧。
- 对 Fuchsia 平台和外部运行时进行单独验证：目前，大量的树内 Dart 用例采用集成测试的形式，旨在验证 Dart 和 Flutter 运行时的运行情况。示例包括针对 Dart 运行时运行的界面、FIDL 和诊断领域中的集成测试。这些测试就是一个例子，说明目前尚未强制执行产品/平台分离。它们会将平台本身视为要运行的产品，然后尝试在同一测试中同时验证平台的协定和（产品）运行时。
- 减少对 Fuchsia SDK 中下游项目的依赖：Fuchsia SDK 会发布一组 Dart 库（例如 SL4F），这些库旨在针对特定版本的 Dart 和 Flutter 运行时运行。如需验证这些库的运行情况，您需要使用滚动器更新 GI 中的 Dart 和 Flutter 运行时，然后在树中编写基于 Dart 的测试。最终，这会导致与上述相同的可维护性和产品/平台分离问题。
- 鼓励向基于 ffx 的工作流程转变：禁止对新宿主工具使用 Dart，将会促使创建更多基于 ffx 的工作流程。
- Dart 语言政策：此提案实际上是现有语言政策的更强版本，该政策规定平台组件不得使用 Dart 编写，现在已扩展到平台测试和托管工具。
利益相关方
教员：
abarth@google.com
Reviewers:
- akbiggs@google.com（Fuchsia 上的 Flutter）
- fmeawad@google.com（效果）
- sanjayc@google.com（工作站）
- yuanzhi@google.com (SL4F)
- shaibarack@google.com（技术债 WG）
咨询了：
- 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”中添加新的性能测试。
生成初始列表后，我们将实现在构建时强制执行许可名单的机制。此实现将使用 GN 可见性限制向 build 中添加新的 dart_library、flutter_library、dart_test、flutter_test 和 dart_tool 目标。这样一来，其行为将与许可名单（例如驱动程序共享库许可名单）类似。
此时之后，如果 build 树中存在 Dart 程序但不包含在许可名单中，树内 GN build 将发出构建时错误。我们不会通过许可名单机制限制现有 Dart 程序的扩展，但在设计和代码审核中会不鼓励这样做。
性能
这只是政策和构建系统方面的变更，预计不会对性能产生影响。
向后兼容性
许可名单的初始内容将包含树中的所有现有 Dart 程序，因此强制执行将完全向后兼容。
安全注意事项
这只是政策和构建系统方面的变更，预计不会对安全性产生影响。
隐私注意事项
这纯粹是政策和构建系统方面的变更；我们预计不会对隐私造成影响。
测试
我们将许可名单作为构建时检查来实现，这意味着主要测试是 Fuchsia 源代码树是否继续正确构建。如果树继续正确构建，则表示所有 Dart 程序都符合许可名单的限制。
文档
此 RFC 旨在记录我们创建许可名单的意图。
我们需要更新面向开发者的部分文档：
- 语言政策：更新了 fuchsia.dev 语言政策，以反映这些政策变更。
- 教程：在介绍如何编写 Dart 程序的 fuchsia.dev 文档中添加了警告和许可名单说明。
缺点、替代方案和未知情况
此方案的主要缺点是，在树中编写新的 Dart 程序将变得困难。由于 Dart 历史悠久且易于使用，因此 Fuchsia 开发者在编写主机工具时通常会使用 Dart。
如果无法使用 Dart 选项，则编写与 Fuchsia 设备交互的主机工具的唯一可行替代方案是实现 ffx 插件。我们希望开发者能接受这种做法，因为 ffx 已经是使用 Fuchsia SDK 编写此类宿主工具的官方推荐方式。
该提案的一个主要未知问题是，如何在 Dart 程序严格采用外部构建方式的情况下，实现 Dart 与 Fuchsia 平台的深度集成（FIDL 绑定、一致性测试）。目前，我们还不知道如何根据 Fuchsia SDK 版本协调外部 dart 库的版本。flutter-on-fuchsia 团队打算在后续的 RFC 中解决这些未知问题。
在先技术和参考文档
适用于 Dart 的现有 Fuchsia 语言政策：语言政策
此 RFC 提出了与驱动程序共享库许可名单类似的基于许可名单的强制执行机制：驱动程序共享库许可名单 RFC