Add support for customizing project groups

[kwridan]

Currently generated projects have the following structure:

All project (and target) related files are included within the Project group. This is a great option to keep the root of the project clean and more manageable.

Replicating the file system without an intermediary Project folder can sometimes be more favorable

e.g.

A few motivations for this:

• When support is added for non source project files (e.g. READMEs and Documentation) some of those are traditionally found at the root of the project
• Having a Project group could lead to errors where developers add new source files to it while developing as it may be confused with a folder on disk. Those files won't be part of the project when re-generating it, of course the same is true when adding to the root in either case

Note: Support for this could be considered for the generator library (#205)

Related

• Support playgrounds inside of a workspace (and maybe other document formats too) #258: Workspace structure
• Support adding file/folder as reference #202: Support folder references

[kwridan]

For reference, one approach I attempted for this was in #257

The follow on from that could be via extending ProjectGroup

enum ProjectGroup: Hashable {
    case root // or main
    case group(name: String)
}

The bit that required more thought was how to ensure the order of main group is maintained. A simple optioned that was attempted was requiring a separate sort() pass ahead of project generation. The cleaner alternative was to figure out a way to generate all groups in one go at the end once all elements (and their hierarchy / structure) is known.

[pepicrft]

Isn't this already done @kwridan ?

[kwridan]

Not yet, would like to add a .root option once I get a chance.

[pavel-trafimuk]

@kwridan any news with it?
I will be happy to see it in "additional files")

[adellibovi]

@kwridan, do we have any good reason to keep Project at all? I agree with you that it can be much cleaner without and I don't see benefits on supporting the two options. WDTY? Also, if developers have different folders they can always group it quite easily by creating a new directory, in fact, if they are a fan of Project root directory they can just create it :)

[kwridan]

Indeed it can be flattened to keep things easier* rather than offer the configuration option. When first migrating to leverage Tuist I thought it was odd and preferred not having the Project group, but after a few years now it didn't matter so much. The value it adds was making it easier to spot the file system files from the the Xcode products and frameworks - though perhaps not a big of a problem these days

• Project: Where all the file system files appear
• Manifest: Tuist used to automatically include the manifest file in all generated projects in this Group - no longer the case
• Frameworks: Tuist adds any SDK / pre-compiled frameworks to this group to help keep the root clean
• Products: Xcode used to show you a products group, now it's hidden by default

* A while ago I attempted this but sadly hit an implementation detail issue which made it a bit trickier (needing to sort the main group ad-hoc at the end) but perhaps we'll find a simple way to achieve this.

[DandyLyons]

Is this still bountied? It doesn't appear to be added to Algora.

[algora-pbc]

💎 $100 bounty • Tuist

Steps to solve:

1. Start working: Comment /attempt #268 with your implementation plan
2. Submit work: Create a pull request including /claim #268 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to tuist/tuist!

Add a bounty • Share on socials

[pepicrft]

Done @DandyLyons

[unworld11]

i would love to claim this,
can i get some clarity on what the requirements are.
there have been a lot of iterations with the comments
thankyou :)