Tooling Monorepo

[JoshuaBatty]

Rendered

---

Note

Adds an RFC proposing a new forc-tooling monorepo for operational tooling and CLI wrappers, keeping AST-aware binaries in Sway, with defined migration, distribution, CI, and release processes.

• RFC Added: rfcs/0017-tooling-monorepo.md introducing a split into a new forc-tooling monorepo.
  • Scope:
    • Move CLI wrappers (forc-fmt, forc-lsp, forc-doc, forc-migrate) and operational tools (forc-node, forc-client, forc-crypto, forc-wallet) to forc-tooling.
    • Keep AST-aware implementations (swayfmt, sway-lsp, sway-doc, sway-migrate) in sway.
  • Distribution: Update sway-nightly-binaries, fuelup, and fuel.nix to source binaries from both repos.
  • CI & Compatibility: Separate CI pipelines; track cross-repo compatibility via compatibility.toml.
  • Release Pipeline: Independent crate releases from forc-tooling; atomic installs via dual manifests.
  • Implementation Plan: Bootstrap repo, migrate tools, introduce wrapper crates, update distribution, rollout/monitor.
  • Release Tooling Options: Consider release-plz, cargo-smart-release, cargo-unleash.
  • Notes: Drawbacks, alternatives, prior art, and unresolved questions documented.

^{Written by Cursor Bugbot for commit 9f0d425. This will update automatically on new commits. Configure here.}

[kayagokalp]

This looks great to me! Only thing we might want to clarify/discuss is versioning as the binary that invoking compiler capabilities now will be decoupled from the sway repo.

As RFC discusses with the ability to version different packages independently, we should be able to continue following those version sets (like forc-fmt is actually at the same level as the compiler releases) while keeping rest of the tools like forc-client independent from these bumps.

I think we can also revive a simplified version of "releasy" which is going to actually just watch for releases in sway repo and open bump PRs on the tooling monorepo (like sway-core bumped on sway side etc). This can be useful for situations like getting latest language features released into forc-fmt semi-automatically, as there will be a PR already.

I am curios whether we consider forc as a tooling monorepo thing or sway monorepo thing? I feel like it should be tooling monorepo while its sway repo dependency is forc-pkg but without an automatic process described as above, language releases will require an additional PR merged. It is not the end of the world but something to consider

[xunilrj]

It would be interesting to allow sway CI to trigger some upstream tests. The new tooling repo is one of them.

In this way, we would know that something is breaking. This CI task would not block merge, but would signal to someone else that changes are coming.

[cursor]

PR Summary

Adds an RFC proposing a separate forc-tooling monorepo, keeping AST-aware binaries in sway, with defined CI, release, and compatibility tracking.

• RFC Added: rfcs/0017-tooling-monorepo.md
  • Proposes creating a dedicated forc-tooling monorepo for CLI wrappers and operational tools while keeping swayfmt, sway-lsp, sway-doc, sway-migrate in sway.
  • Repository boundaries:
    • sway: compiler, language services, AST-aware binaries
    • forc-tooling: forc-fmt, forc-lsp, forc-doc, forc-migrate (wrappers), forc-node, forc-client, forc-crypto, forc-wallet, tracing/deploy tools
  • Distribution: update fuelup, fuel.nix, and nightly pipelines to source tooling from the new repo.
  • CI/Release: independent pipelines; tooling publishes separately; atomic installs supported.
  • Compatibility tracking: auto-generate releases.toml from Cargo.lock per release.
  • Implementation plan: bootstrap repo, migrate operational tools, introduce wrappers, adapt distribution, and monitor rollout.
  • Tooling options: outlines multi-crate release tools (release-plz, cargo-smart-release, cargo-unleash).
  • Notes drawbacks, rationale/alternatives, prior art, and unresolved questions.

^{Written by Cursor Bugbot for commit 60dfcb3. This will update automatically on new commits. Configure here.}