Override Manifest cache policy about tuist

[pepicrft]

@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.

[Ernest0-Production]

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.swift file, when creating a target and if resources were available, I generated a ResourceType+Generated.swift file.

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.swift was 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.

[pepicrft]

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