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] 表格标记工作区并列出成员通配符；所有其他内容——依赖图、构建顺序、发布顺序、变更影响、路径依赖重写映射——都从成员自己的 gleam.toml 文件中计算得出，从不手动声明。

这就足以支持日常命令：

以及发布（我真正构建它的目的）：

publish 处理了过去我最讨厌的 bash 脚本——路径依赖重写：每个工作区路径依赖都会变成根据该依赖当前版本派生的 Hex 要求，执行 gleam publish，然后恢复原始 gleam.toml——即使失败也会恢复。已发布的版本会被跳过，因此重新运行部分失败的发布是安全的。

有主见但模块化

Trellis 是有主见的，但各个组件是模块化的，因此你可以只采用你需要的部分。如果你只想要 run 和 graph，可以使用它们并保留现有的发布流程。我还将变更日志引擎作为原生、兼容 Changie 的功能集成进来——片段位于 .changes/unreleased/、可配置的种类和 bump 规则——因为拥有一个单一二进制文件来端到端处理整个工作区场景（无论在 CI 还是本地）都很方便。但如果你不喜欢它的做法，可以替换掉。

我也欢迎在 trellis 仓库上提交 bug 报告、功能请求、拉取请求等。它是 MIT 许可的开源软件。

它以单个预构建二进制文件的形式发布（shell 安装程序、Homebrew、mise 或 cargo install），因此在 CI 中安装只需大约一秒。完整文档位于 trellis.tylerbutler.com。如果你在一个仓库中构建多个 Gleam 包，不妨试一试。