Adopt Tuist to manage the project

[pepicrft]

Tuist removes the intricacies, inconvenience, and slowness of working at scale with Xcode. This PR migrates CodeEdit to use Tuist.

• Extract the build settings into .xcconfig files using Tuist's command for that
• Extract the dependencies into Tuist/Package.swift, ensuring that they align with the current project's requirements.
• Remove InspectorSidebarToolbarTop.swift, FindNavigatorResultFileItem.swift, and NavigatorSidebarToolbar.swift, which don't seem to be used anywhere.
• Adjust the CI pipelines to use Tuist
• Update the documentation to mention the Tuist requirement
• Manual testing by someone familiar with all the project workflows and the app itself

[austincondiff]

@CodeEditApp/maintainers What do y'all think about the work done here? Tuist has the potential of doing some good for our project. There may be some concern around the higher barrier to entry because contributors now would need to install Tuist as opposed to pulling down the code and running the project.

@pepicrft can you please explain to everyone in short what benefits Tuist could bring to an open source project like ours despite this concern?

To learn more on your own, visit tuist.io.

[0xWDG]

URL Seems to be incorrect

[0xWDG]

This url leads to a 404 page, do you mean https://docs.tuist.io/guides/quick-start/install-tuist ?

[pepicrft]

@pepicrft can you please explain to everyone in short what benefits Tuist could bring to an open source project like ours despite this concern?

Hey folks!
Sorry for the late reply, but my focus has been scattered across many places.

Tuist makes the intricacies of modular Xcode projects more manageable, prevents implicit configuration that might lead to slowness and unreliability of some Xcode features, and allows optimizations like selective test execution or binary caching that might be handy at a particular scale. It's been battle-tested by large organizations for more than seven years.

I'm very biased in the value that this provides, but I think it's awesome! You know better than me what the situation of this codebase is and whether it might benefit from the above value. If you think so, I'd be happy to push this to the finish line and give you access to some of those features to speed up workflows.

[austincondiff]

Thanks, Pedro! We’re wondering if Tuist can help address a few challenges we’ve been facing in CodeEdit with our separate packages (CodeEditTextView, CodeEditSourceEditor, CodeEditLanguages, CodeEditCLI, CodeEditKit, etc.). There is a high barrier to entry for our contributors when setting up their local environments. Do you think Tuist can simplify this by automating the process, making it easier for contributors to work across multiple repos without manually configuring everything?

We’re hoping these improvements can make the project more efficient.

Looking forward to hearing your thoughts!

[pepicrft]

There is a high barrier to entry for our contributors when setting up their local environments.

Do you have some examples? Besides requiring Xcode's toolchain, what are the other elements that add friction? Once I understand that better, I might be able to make some suggestions. Perhaps it's not Tuist what you need :)

[austincondiff]

@pepicrft Sure, here’s an example of what I’m talking about.

To set the stage we have CodeEdit which depends on CodeEditSourceEditor which depends on CodeEditTextView. Each exist in separate repositories. The last two are packages.

Let’s say a new contributor comes along and says, “I’d like to contribute to CodeEdit.” They go to the CodeEdit repository, fork it, pull down the code and start looking for an issue to take. When they find one, it has to do with the source editor.

They dig through the code only to discover the code needing to be changed is in CodeEditSourceEditor. So they go to that repo in GitHub, fork the repo, pull it down, then they need to temporarily add their local copy of CodeEditSourceEditor to their CodeEdit project.

They work on the issue and are about done when they find that CodeEditTextView needs adjustment in order for everything to work correctly, so again they need to go to the repo, fork it, pull it down and add the local copy to CodeEdit and CodeEditSourceEditor temporarily, make the change, and make sure everything works across the board.

Once they are finished they need to remember to remove the local package references, make three separate commits, and open three separate PRs in each repo.

Once merged, we need to then make a release for CodeEditTextEditor, bump the version to pull in the changes to CodeEditSourceEditor. Then release CodeEditSourceEditor and bump both CodeEditTextView and CodeEditSourceEditor in CodeEdit to pull in all of the changes.

@CodeEditApp/maintainers please correct me if I have any of this wrong.

Now, some of this is necessary and I am not complaining because there are a lot of benefits in organizing it this way, but I’d like to use any tool available to make things as efficient as possible where it makes sense.

[pepicrft]

Thanks @austincondiff :). Then I don't think that's the type of problem that we are trying to solve with Tuist, but happy to help anyway. What's the motivation between the multi-repo setup? If it's useful, we committed to a monorepo structured at Tuist since the beginning, and it has been quite useful because it prevented that type of friction. Eventually, as APIs got more mature, we extracted the pieces that made sense standalone, that didn't change much, and that we planned to reuse across repositories and release following its own cadence.

[austincondiff]

@pepicrft ahh yeah, a monorepo could definitely help here and this has crossed my mind before. @thecoolwinter what are your thoughts here? Maybe we can take this conversation to Discord.

Tuist documentation says

Simplify modularization: As projects grow and span multiple platforms, modularization becomes crucial. Tuist streamlines this complexity, offering tools to optimize and better understand your project's structure.

Maybe I mistook what was meant here. This is why I brought this up in the first place.

[pepicrft]

@austincondiff that might make people believe that we are solving the challenges of working across repositories, but this is not an Xcode-specific problem, and hence we don't think it should be addressed by Tuist. That problem spans technologies and ecosystems. Multi-repos and mono-repos come with pros and cons, so you need to assess which model is best for the project.
My recommendation is always to lean on the mono repo for the modules that are still maturing and change regularly. Based on what you said, it seems this is the case for you. Happy to look at CodeEdit's case more closely, but I'd need to understand more about the multi-repo decision and the motivations behind it.

[thecoolwinter]

@pepicrft thanks for your time working on this! I appreciate the effort you’ve been able to put towards this. We’re going to close this PR for now and continue to use Xcode’s project management system. We’ve got a few specific things driving this decision:

• One of Tuist's big pulls seems to be CI improvements. While it seems like a good system, we already have a CI system set up with a pretty fast Mac mini kindly donated by MacStadium. If we eventually become a faster moving team, something like what Tuist is offering would be more tempting. Right now though, we’ve put a lot of effort into our existing system and don’t have the manpower to move to a whole new one.
• In our case, Xcode conflict issues are manageable. I think this again due to being a smaller and pretty slow moving team. If we do eventually have some full time devs on this project, I think Tuist will be considered again due to a faster moving team.
• Tuist doesn’t fully support homebrew. Requiring new contributors to install new tools is already frustrating for someone wanting to jump in. On top of that, needing to install a whole new package manager creates a high barrier to entry. If homebrew binaries were signed and regularly updated having to install a tool might be more palatable.

Tuist seems like a great tool for a slightly larger, faster moving team looking to save time. Again I appreciate your time with this PR as I know it’s been drug out for a while.

[pepicrft]

Thanks a lot @thecoolwinter for the thorough rationale.

As I said earlier, if you don't have the challenges that Tuist is addressing, then it doesn't make sense to bring the tool. I'd like to point out a couple of things though that seems to have been misunderstood:

• Tuist is not a CI solution and therefore it doesn't pull anyone from their existing CI system.
• Tuist supports Homebrew officially. We don't recommend it because it leads to non-determinism across contributors, which is in fact a source of headaches in collaborative projects.