| RFC-0176：禁止在 Fuchsia 來源樹狀結構中使用新 Dart 程式 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 如要將新的 Dart 程式新增至 Fuchsia 來源樹狀結構，就必須取得豁免。 |
| 問題 | |
| 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 來源樹狀結構中各個專案的目前狀態。這本分錄帳通常會透過稱為「roller」的自動化程序進行更新。
提振精神
Flutter on Fuchsia 團隊希望從樹狀結構內環境中移除對 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 執行階段的運作情形。範例包括在 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 (Flutter on Fuchsia)
- fmeawad@google.com (成效)
- sanjayc@google.com (工作站)
- yuanzhi@google.com (SL4F)
- shaibarack@google.com (Tech Debt WG)
諮詢：
- chaselatta@google.com (OOT)
- jaeheon@google.com (UI)
- crjohns@google.com (診斷)
- yifeit@google.com (FIDL)
- dannyrosen@google.com (Tech Debt WG)
- mangini@google.com (開發人員關係)
社會化：
這個 RFC 的初始社交化提案經過所有受影響團隊的個別對話，這些團隊的名稱列於上方的「審查者」或「諮詢對象」中。隨後，RFC 作者在「2022 Fuchsia SDK Summit」期間舉辦了工作坊，討論本 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 提出的許可清單式執行機制，與驅動程式共用程式庫許可清單類似：Drivers Shared Library Allowlist RFC