feat(cli): add opt-in SwifterPM install resolution

[P2] Consider linking SwifterPM as a library instead of bundling and shelling out to its CLI.

Because Tuist controls SwifterPM, packaging a second signed binary and invoking it through string arguments feels heavier than necessary for a supported integration. It also makes the contract harder to test and easier to drift: Tuist can pass flags that SwifterPM parses differently or ignores, errors are only process-level, and release packaging now has to keep Tuist and the bundled SwifterPM binary aligned across platforms. I’d consider exposing a SwifterPMCore library target, keeping the swifterpm executable as a thin wrapper around it, and having Tuist call the typed resolver/restorer APIs directly. Shelling out is fine for an opt-in spike, but I would not make that the long-term integration shape for a tool we own.

@fortmarek I agree. I changed the integration to link SwifterPMCore directly and removed the vendor/swifterpm release packaging path. tuist install now stays on the existing swift package path unless TUIST_USE_SWIFTERPM is present, and the opt-in path builds a typed SwifterPMResolutionRequest instead of passing a CLI string contract through a subprocess.

While validating the generated Xcode project I hit a SwifterPMCore compile issue with swift-subprocess trait-gated .data(limit:) helpers in generated projects. I opened https://github.com/tuist/swifterpm/pull/13 to make the core target use the non-trait .bytes(limit:) API. Once that is released, I’ll move this PR to the new tag and finish the tuist install validation here.

@fortmarek Follow-up on this: SwifterPM 0.6.1 is out and this PR now depends on SwifterPMCore from that release, so there is no bundled swifterpm binary and no subprocess boundary for the opt-in path.

I also validated the existing .build case in this repo. With an existing SwiftPM .build, TUIST_USE_SWIFTERPM=1 tuist install succeeded, SwifterPM reused .build as its scratch directory, and it replaced only resolved package checkout/download entries with symlinks into its cache. I then ran tuist generate tuist ProjectDescription --no-open and built the tuist scheme in Xcode successfully against those symlinks.

🛠️ Tuist Run Report 🛠️

Previews 📦

Tests 🧪

Flaky Tests ⚠️

• TuistUnitTests: 3 flaky tests (View all)

Builds 🔨

Bundles 🧰

@fortmarek I went through each requested item against the current Tuist PR and the released SwifterPM 0.6.1 tag:

• Registry cache key and archive validation: fixed by tuist/swifterpm#12, which is included in 0.6.1. Registry source and archive paths now include registry URL plus checksum, and cached registry archives are SHA-256 validated before reuse.
• --replace-scm-with-registry: fixed by tuist/swifterpm#12 and wired through this PR. Tuist maps --replace-scm-with-registry and --use-registry-identity-for-scm into SwifterPMResolutionRequest.scmToRegistryTransformation, and SwifterPM applies that transformation in PackageResolver.transformedDependencies.
• mise and release assets: this PR no longer adds or bundles a swifterpm binary. Tuist links SwifterPMCore directly from Package.swift, and 0.6.1 also publishes the Linux asset, so the old mise binary asset mismatch no longer applies.
• Manifest cache location: fixed by tuist/swifterpm#12, included in 0.6.1. The package-info cache is written under scratchDir/swifterpm/package-info, and raw manifest dumps use .build/swifterpm/manifests/package.json instead of .swifterpm-manifest.json next to Package.swift.
• Transitive local package dependencies: fixed by tuist/swifterpm#12, included in 0.6.1. ManifestFileSystemDependencyGraph.collect now walks filesystem dependencies transitively and is used for resolution, package-info cache writing, binary artifact restore contexts, and workspace state.
• Version metadata: the only remaining real gap was SwifterPM’s user-visible metadata still saying 0.5.1 or 0.3.0. I opened https://github.com/tuist/swifterpm/pull/14 to update the CLI version, Bazel module metadata, plist version, Bazel tool default, README example, e2e example, and the guard test to 0.6.1.

Validation I ran:

• In SwifterPM: swift test --filter MainTests
• In Tuist: xcodebuild test -workspace Tuist.xcworkspace -scheme Tuist-Workspace -only-testing TuistSupportTests/SwiftPackageManagerControllerTests CODE_SIGNING_ALLOWED=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY=""

The Tuist test passed 11 controller tests, including the opt-in SwifterPM request path, SCM registry transformation forwarding, conflict handling, and update path. While building that selected test target, Xcode compiled through the generated workspace using the existing .build/registry/downloads symlink paths backed by ~/.cache/swifterpm, so the existing .build scenario is still covered locally.