Trellis：Gleam 單一倉儲的工作區工具

隨著我在 Gleam 生態系中建立更多函式庫，我善加利用了 Gleam 對檔案系統依賴的支援。 路徑依賴讓您可以建立包含多個 Gleam 套件且連結、一起建置的本地工作區。這很棒！

我建立的第一個工作區是我的 lattice 專案，這是一組 CRDT 實作的集合。 每個資料結構都各自獨立封裝，因此您可以只依賴計數器或只依賴 OR-set，而不用引入其他所有內容，且每個套件都能獨立進行版本控制與發佈。 這顯然是 lattice 合適的架構。

這也暴露出兩個問題。

依正確順序執行。 在單一套件內，Gleam 能很好地處理路徑依賴——編輯依賴的原始碼，下一次建置消費者時就會自動取用。但工作區感知就到此為止：gleam build、gleam test 與 gleam publish 每次都只能針對單一套件目錄運作。若要在整個工作區執行測試——或只針對變更實際影響的套件執行——就必須在 justfile 中手動維護依拓撲排序的套件清單，再用 bash 逐一序列執行。每新增一個套件都得手動加入清單，且當依賴圖演進時，也沒有機制驗證順序是否正確。兩個套件時還算勉強，但之後就越來越難以為繼。

發佈。 將多套件工作區發佈到 Hex 需要一堆 bash 膠水：手動計算發佈順序，以及——最糟糕的部分——在發佈時將每個套件的路徑依賴改寫成合法的 Hex 版本需求，之後再把原始內容還原。這一步最令人煩躁且容易出錯，因為半途失敗的發佈會讓您的儲存庫處於改寫後的狀態。

我最初也對如何在套件間進行版本控制感到困惑，而我認為應該採取特定做法：每當有面向使用者的變更時，都以小型片段檔案記錄下來，發佈時再將累積的片段批次轉成版本更新與變更日誌。幸好有一個名為 Changie 的優秀工具能自動化這個工作流程，我強烈推薦。我在 Rust 專案（包含本專案）中都使用它。

當第三個專案也需要相同的 Gleam 工作區基礎建設時，我決定徹底解決這個問題。

Trellis 登場

我在這個領域有相當豐富的專業經驗，因此我寫下使用情境、草擬 CLI，然後派 Fable 5 來實作。 我對產出的結果相當滿意，而且我已經在自己的專案中使用它。

成果就是 trellis——trellis 當然就是 lattice 生長的框架。

設計原則：可推導的設定都不需另外設定，必須重複的內容都要驗證。 沒有獨立的工作區設定檔。只要在根目錄的 gleam.toml 中加入 [tools.trellis] 表格，即可標記工作區並列出成員 glob；其他所有內容——依賴圖、建置順序、發佈順序、變更影響、路徑依賴改寫對應表——都從成員自己的 gleam.toml 檔案計算而來，永不宣告。

這就足以應付日常指令：

以及我真正為了它而建置的發佈功能：

publish 會處理過去我最討厭的 bash 腳本：將每個工作區路徑依賴改寫成根據該依賴目前版本衍生的 Hex 需求，執行 gleam publish，然後還原原始 gleam.toml——即使失敗也會還原。已發佈的版本會被跳過，因此重新執行部分失敗的發佈是安全的。

有主見但模組化

Trellis 雖然有主見，但各個元件都是模組化的，您可以只採用您需要的部分。如果您只需要 run 與 graph，可以使用這兩個指令，並保留現有的發佈流程。我也將變更日誌引擎以原生、相容 Changie 的功能內建——片段放在 .changes/unreleased/，可設定種類與 bump 規則——因為擁有一個單一二進位檔就能在 CI 與本地端完整處理整個工作區情境，是很方便的事。但如果您不喜歡它的運作方式，可以替換掉。

我也歡迎在 trellis 儲存庫 上提交錯誤回報、功能需求、拉取請求等。它是 MIT 授權的開源軟體。

它以單一預先建置的二進位檔發佈（shell 安裝程式、Homebrew、mise，或 cargo install），因此在 CI 中大約一秒就能安裝完成。完整文件位於 trellis.tylerbutler.com。如果您在同一個儲存庫中建立多個 Gleam 套件，歡迎試用。