Override Manifest cache policy
What problem or need do you have?
I want to be able to control the input data for caching the project manifest.
Motivation:
In the manifest files I have logic that requires reading the current directory at the time of generation. This is required to automate some actions in my project that are not available in tuist at the moment, and it hardly makes sense to include them in tuist itself, because There can be many such scenarios in different projects.
Potential solution
In the simplest case, it makes sense to add the ability to completely disable the manifest cache, without using the command tuist clean manifests which clears all manifests of all projects on my computer.
Ideally, the ability to specify a list of additional files for which checksum will be calculated.
For example, add a parameter to Config:
let config = Config(
manifestCache: .enable(
extending: [Path], // Support glob path
)
)
let config = Config(
manifestCache: .disabled
)
macOS version
15
Tuist version
4.10
Xcode version
15.3
@Ernest0-Production Manifests that contain logic that depends on the current directory is generally discouraged
This is required to automate some actions in my project
Could you share an example so that I can provide with a solution or path forward.
Could you share an example so that I can provide with a solution or path forward
Hello. I really wanted to be able to write a custom mechanism for automatically generating type-safe access to target resources via SwiftGen.
The limited API of Tuist with the resource synthesizer did not really suit me, and I decided to add my own side effects to the project generation (tuist generate):
- in the
Project.swiftfile, when creating a target and if resources were available, I generated aResourceType+Generated.swiftfile.
extension Target {
func feature(name: String) -> Target {
Target.target(
name: name,
scripts: {
let resourcesPaths: [String] = FileManager.shared.subpaths(in: <path/feature/resources>)
// some magic for filter resources by resource kind
let resources: [ResourceType: [Path]] = resourcesPaths.reduce(....)
return resources.map { resourceType, inputPaths in
TargetScript.pre(script: "swiftgen run \(resourceType) --input .... --output \(inputPaths.join(separator: " ")) ")
}
}()
)
}
}
- Before generating the project, I generated a checksum of the project file structure. If
ResourceType+Generated.swiftwas deleted, and/or a new resource type appeared (localization or fonts, for example), then the user would invalidate the cache and recompile and run the manifest, causing my side effects to be called again.
I came to this decision because I tried many other right and wrong approaches. The reason for this is that it is important for me to have access to the code that I use to generate the project.
The ProjectAutomation API is very limited and does not allow you to change the project. And using XcodeProj forces you to go down to a lower level, which does not seem very convenient.
Gotcha. As you noted, we'd love to expose an API for this because ProjectAutomation is very limited. But before we get there, we want to implement a fully-fledged plugin system with great ergonomics.
Until that exists, I recommend taking a different approach where the manifests don't have side effects. If we open an API that implicitly accepts imperative code depending on file-system files, we'd be opening the door for for complexity in the manifests, and potentially the breakage of features that assume no side effect in those files.
Since your logic requires accessing the declaration of your project, you can implement a small CLI, maybe in an Xcode project, that imports the dynamic ProjectDescription.framework framework distributed with your Tuist installation. Then you can have a generation pipeline that looks like this:
#!/usr/bin/bash
generation_tool # It's noop if nothing has changed
tuist generate