fix(cli): scope proto SPM plugins to their generation tasks

What

Move the SwiftPM-backed protoc plugins (spm:apple/swift-protobuf, spm:grpc/grpc-swift-protobuf) out of the global mise.toml [tools] table (and mise.lock) and resolve them per-invocation with mise x inside the proto-generation tasks.

Why

#11466 added those two plugins to the global [tools] table so the new TuistREAPI proto-generation task could invoke protoc with the plugins on PATH. The mise SwiftPM backend builds these tools from source with swift, and any mise install / mise run / mise x resolves the entire [tools] table before doing anything else. On a runner without a Swift toolchain that resolution hard-fails:

mise WARN  swift may be required but was not found.
mise ERROR Failed to install tools: spm:apple/swift-protobuf@1.35.1, spm:grpc/grpc-swift-protobuf@2.1.1
spm:apple/swift-protobuf@1.35.1: No such file or directory (os error 2)
spm:grpc/grpc-swift-protobuf@2.1.1: No such file or directory (os error 2)

Root cause

The plugins are dev-only codegen tools needed solely when regenerating the vendored protos, but they were placed in the global tool set that every job auto-installs. That broke the CLI Canary Release → Resolve canary version job on tuist-linux (failed run): a 5-minute job that only reads git tags to compute the next version, yet auto-installs the full toolchain — including two tools that cannot build without Swift. The previous canary release (06-24) was green; the merge of #11466 introduced the break.

The blast radius is wider than canary: every other workflow that runs mise install unscoped on a Swift-less Linux runner is exposed the next time it runs — blick-learn, cache-deploy, cache-staging-deploy, handbook, helm.

Why this fix over the alternatives

• mise run --skip-tools on the canary step would unblock that one job (and is reasonable hygiene there — it has no business installing erlang/elixir/gradle to read a git tag), but it is a per-call mise run flag and cannot help an unscoped mise install, so the other five Linux workflows stay broken.
• mise use is the wrong primitive: it writes the tool back into a mise.toml, reintroducing exactly the global dependency this removes.
• mise x is ephemeral — it puts the tool on PATH for one command and never touches mise.toml. Scoping the plugins to the tasks that actually need them fixes the root cause for all runners with a two-line removal, and matches the convention generate-cache-proto.sh already used.

generate-cache-proto.sh is updated in the same change: it had quietly come to depend on the same global protoc-gen-swift (its bare protoc --swift_out) and on a parent-shell $(which protoc-gen-grpc-swift-2) — both break once the globals are gone — so each protoc call is now scoped with mise x to make the task self-contained.

Impact

• CLI Canary Release (and every unscoped mise install on a Swift-less Linux runner) no longer attempts to build the SwiftPM plugins.
• No change for developers regenerating protos: mise run cli:generate-reapi-proto / cli:generate-cache-proto resolve the plugins on demand.

Validation

• Ran both cli:generate-reapi-proto and cli:generate-cache-proto with the scoped mise x form; generated output is byte-identical to the previous global-tool form (protoc output depends on the plugin version + proto input, not on how PATH was assembled).
• mise ls --current no longer lists the SwiftPM plugins, confirming a plain mise install will not reference them.

🤖 Generated with Claude Code

No GitHub comments yet.