Define Target Manifest Outside of Tuist Directory
Isaac Halvorson
I'd love to be able to define a module's manifest right next to the code for that module. When you have a large number of modules, it gets difficult to manage them all within the Tuist directory.
I'm envisioning having a
Target.swift
file at the root of my module, that has a let target = Target(...)
in it, similar to how Project.swift
has a let project = Project(...)
.Ideally, Tuist would automatically search recursively for any files named
Target.swift
, but if that's not possible, maybe you could manually specify the path to the file within the project manifest.I don't know the specifics of how this would need to be implemented, or even if it's possible, but I know it would make things easier for me and my team.
P
Pedro Piñera Buendía
Interesting. We are currently doing that with workspaces that reference projects. The only downside that I see is that we'd have more manifests to compile, and that might increase the generation time when the cache hasn't been warmed. Besides having code and definition self-contained, what other value do you see in having a Target.swift?
Isaac Halvorson
Pedro Piñera Buendía: Having the code and definition self-contained would be the main advantage. I see it providing the same advantages as modularizing a project. Isolating the code could limit the chance of side-effects in the rest of the project generation (I generally wouldn't want "regular" developers editing the
Project.swift
file itself, just the definitions for the module they're working on). It would also simplify the project definition files to have each module's definition separate.When you say "we'd have more manifests to compile", do you mean there'd be a
Manifest.xcworkspace
for each target? I was envisioning there still just being the one main manifest workspace, but these Target.swift files would still show up in the project navigator in Xcode.I'm curious to know more about your method of having one xcworkspace with an xcproject for each module. That seems more complex than having each module be a Target, but maybe I'm just overthinking it. Have you run into any issues with that approach?
P
Pedro Piñera Buendía
Isaac Halvorson: I see your motivation. I doubt we'll achieve atomicity because the manifests will always have a dependency with the project description helpers. However, I see the value in having a directory that contains the source code, resources, and also the manifest that describes the module.
I mean due to how Tuist works, every
.swift
that we have to load is an invocation to the Swift compiler, and that has a cost. It's fine if we have a few manifests, but it'll get noticeable if we have a lot of manifest files. There are some optimizations on our side to speed things up, but something we should be cautious about.My advice is to have a single project with all the targets in it and use "tuist focus". The reason why .xcworkspaces exists is (and this is me guessing) Apple's attempt to minimize Git conflicts. The more .xcodeproj, the less likely is to run into Git conflicts. Because Git conflicts are gone with Tuist, I don't think it makes sense to have workspaces.
Isaac Halvorson
Pedro Piñera Buendía:
> I doubt we'll achieve atomicity because the manifests will always have a dependency with the project description helpers.
That's a good point I hadn't considered.
> …every .swift that we have to load is an invocation to the Swift compiler, and that has a cost.
Ah yeah, that makes sense.
> My advice is to have a single project with all the targets in it and use "tuist focus".
Gotcha, that's the way we're doing it now, so we should be good.
Thanks for the extra context and information! I agree now that this probably isn't a great idea, at least as currently proposed. I'll keep thinking about it though, and see if there's a way to potentially make it work in a reasonable way down the road.
Feel free to mark this request as "not going to do" if that's a thing Canny allows for.