Hive
fix(cli): respect configured SwiftPM scratch paths
GitHub issue · Closed
Summary
Respect the configured SwiftPM scratch path across Tuist instead of hardcoding .build in a few code paths.
Related to #6009.
Context
SwiftPM’s scratch directory is mutable workspace state. It defaults to .build, but it can be customized through SwiftPM arguments passed via installOptions in Tuist.swift.
Tuist already respects that configuration in some places, but other paths still assume .build, which leads to inconsistent behavior when a custom scratch path is used.
This PR does not try to make worktrees share one scratch directory. The shareable optimization is SwiftPM’s cache. Scratch path should remain worktree-local.
Changes
- Reuse the existing scratch directory locator anywhere Tuist still assumed
.build - Update dependency cleaning and outdated dependency checks to use the resolved scratch directory
- Update generator and editor heuristics that depended on literal
.buildpaths - Add coverage for custom scratch-path behavior
- Preserve the default
.buildfallback
Test Plan
Added and updated relevant unit tests for custom scratch-path behavior.
After digging into SwiftPM’s workspace layout, I don’t think sharing a scratch directory across worktrees is the right direction.
- Scratch path is a mutable directory, so attempting to share it across worktrees can lead to unpredictable issues.
- In practice that means shared checkouts, build intermediates, plugin and macro outputs, registry downloads, and lock files can leak across branches or contend with each other.
- If one worktree ends up with corrupted dependency state, cleaning the shared scratch directory can also disrupt the others.
The safer scope for this PR is making Tuist consistently respect a configured SwiftPM scratch path instead of hardcoding .build in a few places. The shareable optimization here is SwiftPM cache, not scratch.