| 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 rollers、third_party/dart->GI rollers (適用於 3p Dart 套件)，以及 Dart 分析工具的樹狀結構內使用情形。
- 提高產品/平台分離程度：即使有允許清單，Fuchsia 產品擁有者仍可透過樹狀結構外產品組裝，將 Dart 和 Flutter 併入產品。樹外產品組裝將成為產品擁有者將 Dart 或 Flutter 納入產品的唯一機制。這會在平台產品界線的產品端，清楚劃分 Dart 和 Flutter 執行階段。
- 分別驗證 Fuchsia 平台和樹狀結構外執行階段：目前樹狀結構內有大量 Dart 用法，都是以整合測試的形式存在，旨在驗證 Dart 和 Flutter 執行階段的運作情形。例如，在 UI、FIDL 和 Diagnostics 網域中，針對 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 (Workstation)
- yuanzhi@google.com (SL4F)
- shaibarack@google.com (技術債工作組)
已諮詢：
- chaselatta@google.com (OOT)
- jaeheon@google.com (UI)
- crjohns@google.com (診斷)
- yifeit@google.com (FIDL)
- dannyrosen@google.com (技術債工作組)
- mangini@google.com (開發人員關係)
社交：
這項 RFC 的初步提案已與所有受影響的團隊進行個別對話，這些團隊列於上方的「審查者」或「諮詢」部分。RFC 作者隨後在「2022 年 Fuchsia SDK 峰會」期間，針對這份 RFC 的內容舉辦了研討會。
設計
Fuchsia 上的 Flutter 團隊會維護 Dart 程式清單，這些程式可存在於樹狀結構內 Fuchsia 建構作業的建構圖中。這個清單的初始內容會是樹狀結構內的所有現有 Dart 程式。
設計政策和執行機制時，我們盡量遵守下列原則：
- 漸進式：雖然 Flutter on Fuchsia 團隊最終希望移除樹狀結構內的 Dart 程式，但這項遷移作業必須逐步完成，以免對樹狀結構內現有的 Dart 使用者造成負面影響。換句話說，我們不會在找到合適的替代方案前，刪除任何樹狀結構內的負載 Dart 程式。由於無法立即遷移，我們「必須」先建立允許清單，再開始遷移任何樹狀結構內的 Dart 程式。這樣一來，系統會減緩或停止新增計畫，但不會對現有計畫造成負面影響。
- 包容性：儘管樹狀結構內 Dart 的使用量已逐漸減少，且平台元件可能並非以 Dart 編寫，但以 Fuchsia 為基礎建構的產品仍會持續擴大 Dart 的使用範圍。我們「必須」保留產品擁有者繼續使用樹狀結構外 Dart 的能力，以用於自己的元件和主機工具。因此，許可清單「不得」套用至任何樹狀結構外的 Dart 程式。
實作
我們會根據樹狀結構內的現有 Dart 程式清單，在 fuchsia.git 中產生初始許可清單。為符合增量設計原則，我們會在效能測試的允許清單中加入萬用字元項目；這個萬用字元項目可讓您在「//src/tests/end_to_end/perf」中新增效能測試。
產生初始清單後，我們會在建構時實作機制，強制執行許可清單。這項實作作業會使用 GN 可見度，限制將新的 dart_library、flutter_library、dart_test、flutter_test 和 dart_tool 目標新增至建構作業。這樣一來，這個許可清單的運作方式就會與驅動程式共用程式庫許可清單類似。
此時，如果建構樹狀結構中存在 Dart 程式，但不在允許清單中，樹狀結構內的 GN 建構就會發出建構時間錯誤。我們不會透過允許清單機制限制現有 Dart 程式的擴充功能，但會在設計和程式碼審查中阻止這類行為。
效能
這純粹是政策和建構系統的變更，預計不會對效能造成影響。
回溯相容性
允許清單的初始內容會包含樹狀結構內的所有現有 Dart 程式，因此強制執行作業完全向後相容。
安全性考量
這純粹是政策和建構系統的變更，預計不會對安全性造成影響。
隱私權注意事項
這純粹是政策和建構系統的變更，預計不會對隱私權造成影響。
測試
我們會在建構時檢查允許清單，也就是說，主要測試是 Fuchsia 來源樹狀結構是否能繼續正確建構。如果樹狀結構持續正確建構，表示所有 Dart 程式都符合許可清單的限制。
說明文件
這份 RFC 說明我們建立許可清單的意圖。
我們需要更新開發人員的幾份說明文件：
- 語言政策：更新 fuchsia.dev 語言政策，以反映這些政策異動。
- 教學課程：在 fuchsia.dev 文件中加入警告和允許清單說明，涵蓋撰寫 Dart 程式。
缺點、替代方案和未知事項
這項提案的主要缺點是，樹狀結構內編寫新的 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