| RFC-0176：不允許 Fuchsia 來源樹狀結構中的新 Dart 程式 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 將新的 Dart 程式新增至 Fuchsia Source Tree，必須符合豁免資格。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2022-06-07 |
| 審查日期 (年/月) | 2022-07-06 |
摘要
建議您為 Fuchsia Source Tree 中的 Dart 計畫建立許可清單。
初始許可清單涵蓋所有這類現有的 Dart 計畫。在 Fuchsia Source Tree 中編寫新的 Dart 計畫需要豁免資格。
系統仍會完整支援在樹狀結構外「產品」環境中編寫以 Fuchsia 為目標的新 Dart 程式。
定義
- Dart 程式：指任何飛鏢程式程式碼的參照，程式庫或完整二進位檔，目標為在主機機器或 Fuchsia 目標上執行。
- In-tree：Fuchsia Source Tree 內的程式程式碼，包括「//src/experiences」的內容以及「//vendor/」的內容。
- 非樹狀結構 (OOT)：指定 Fuchsia 的 Fuchsia 來源樹以外的程式程式碼。
- 全球整合 (GI)：定義 Fuchsia 來源樹狀結構中各種專案目前狀態的中央帳本。這個帳本通常會由名為「rollers」的自動化程序更新。
提振精神
Fuchsia 團隊的 Flutter 希望從樹狀結構內環境中移除對 Dart 程式設計語言的支援。
建立許可清單可協助 Fuchsia 中的 Flutter 團隊追蹤及限制新的 Dart 使用情況，並規劃最終遷移作業。我們將會探討在未來的 RFC 中遷移現有 Dart 計畫的具體計畫。
可能的原因如下：
- 減少 Fuchsia 平台維護負擔：移除樹狀結構內 Dart 支援，可以讓 Fuchsia 平台加快開發速度。所有產品都已開發並完成組合樹狀結構外，Fuchsia 平台就不再需要將 Dart 和 Flutter 執行階段導入 GI。這些元件轉換至 GI 是現今龐大的維護負擔「維護負擔」支援 Flutter->GI 滾動器、third_party/dart->GI 滾動式滾筒套件的 GI 滾輪式滾動器，以及在樹狀結構內使用 Dart 分析工具。
- 提高產品/平台區隔：即使已有許可清單，Fuchsia 產品擁有者仍可透過樹狀結構外結構產品組合，將 Dart 和 Flutter 納入自家產品。產品擁有者可將 Dart 或 Flutter 納入自家產品中，再透過樹狀結構外產品組合。這樣就會在 Platform-Product 邊界的 Product 端清楚分解 Dart 和 Flutter 執行階段。
- 單獨驗證 Fuchsia 平台和樹狀結構外執行階段的驗證：目前樹狀結構內，大量的 Dart 使用行為是以整合測試的形式設計，目的是驗證 Dart 和 Flutter 執行階段的運作。範例包括針對 Dart 執行階段執行的 UI、FIDL 和「診斷」網域中的整合測試。這些測試是目前不強制執行產品/平台區隔的示例。他們會將平臺本身視為用於執行測試的產品，然後嘗試在同一個測試中一併驗證平台的合約和 (產品) 執行階段。
- 減少對 Fuchsia SDK 中下游專案的依賴：Fuchsia SDK 發布了一組 Dart 程式庫 (例如 SL4F)，這些程式庫旨在搭配特定版本的 Dart 和 Flutter 執行階段執行。驗證這些程式庫的作業時，必須使用滾動器更新 GI 中的 Dart 和 Flutter 執行階段，然後樹狀結構內編寫以藝術為基礎的測試。最後，這種做法會產生與上述相同的可維護性和產品/平台區隔問題。
- 鼓勵融合 ffx 式工作流程：禁止將 Duet 用於新的主機工具，可做為建立更高 ffx 工作流程的強制函式。
- Dart 語言政策：本提案實際上是現有語言政策的更強版本，其中平台元件不得以 Dart 編寫，現在則進一步延伸至平台測試和主機工具。
相關人員
講師：
abarth@google.com
審查者：
- akbiggs@google.com (Fuchsia 上的 Flutter)
- fmeawad@google.com (成效)
- sanjayc@google.com (工作站)
- yuanzhi@google.com (SL4F)
- shaibarack@google.com (技術債務人員 WG)
顧問：
- chaselatta@google.com (OOT)
- jaeheon@google.com (使用者介面)
- crjohns@google.com (診斷)
- yifeit@google.com (FIDL)
- dannyrosen@google.com (技術債務 WG)
- mangini@google.com (開發人員關係)
社群媒體化：
本 RFC 的初始社交提案提案涵蓋所有受影響的團隊，列於上方的「審查人員」或「諮詢」中。接著，RFC 作者在「2022 Fuchsia SDK 高峰會」的「2022 Fuchsia SDK 高峰會」期間，舉辦了研討會內容。
設計
Fuchsia 團隊的 Flutter 會維護一份 Dart 程式清單，這些程式可以出現在樹狀結構內的 Fuchsia 內建圖中。此清單的初始內容將是所有現有的 Dart 程式。
在設計政策和強制執行機制時，我們會嘗試謹記以下原則：
- 成效增幅：雖然 Flutter-on-Fuchsia 團隊最終想要移除樹狀結構內的 Dart 程式，但這項遷移必須逐步完成，以免對樹狀結構內現有的 Dart 使用者造成負面影響。換句話說，我們不打算先樹狀結構內刪除任何利用負載的 Dart 程式，而必須先找出適當的替代項目。由於無法立即遷移，我們「必須」先將許可清單加入許可清單，再開始遷移任何樹狀結構內的 Dart 程式。這項作業會減緩或停止新增計畫，且不會對現有程式造成負面影響。
- 多元包容：雖然 Dart 樹狀結構內的使用次數已下降，且平台元件尚未寫入 Dart，但在 Fuchsia 上建構的產品將繼續擴大使用 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 Source Tree 繼續正確建構。如果樹狀結構繼續正確建構，表示所有 Dart 程式都在許可清單的限制範圍內。
說明文件
本 RFC 可做為建立許可清單的意圖。
我們必須更新下列開發人員文件：
- 語言政策：更新 fuchsia.dev 語言政策，以反映這些政策異動。
- 教學課程：在有關編寫 Dart 程式的 fuchsia.dev 說明文件中新增警告和許可清單操作說明。
缺點、替代方案和未知
本提案的主要缺點是，樹狀結構內編寫新的 Dart 程式會相當困難。Fuchsia 開發人員由於過往可用性和易用性，因此在編寫主機工具時經常會要求 Dart 。
如果沒有 Dart 選項，就只能以實作 ffx 外掛程式的方式取代編寫主機工具，以便與節慶裝置互動。我們希望這對開發人員來說是可以接受的，因為 ffx 已成為使用 Fuchsia SDK 編寫這類主機工具的無友善路徑。
本提案最重大的一點是，在嚴格建構 Duet AI 程式的世界中，Dartt 與 Fuchsia 平台 (FIDL 繫結、合規測試) 進行深度整合。我們目前也不知道如何協調樹狀結構外的 GAAR 程式庫版本管理與 Fuchsia SDK 版本。Flutter-on-fuchsia 團隊計劃採用後續追蹤 RFC 來解決這些未知問題。
先前的圖片和參考資料
Dart 現行 Fuchsia 語言政策：語言政策
這個 RFC 提議採用類似的許可清單式強制執行機制，與遷移者共用程式庫的許可清單類似：驅動程式共用程式庫許可清單 RFC