Replies: 1 comment
-
Great post & overall direction for Tuist! Some thoughts on what you have mentioned:
This would be great! We can see demand for this already in posts like: #2496. It would be great to try and formalize what this would look like! If you'd like to collaborate on that, let me know!
This is a great replacement for
🚀
This would be nice, and in line with the vision of making tuist more lean and focused. I do feel that there are a lot of commands that would be better off left as optional (or better yet added as a Tuist org maintained Task if users use it a lot).
Totally agree that with the addition of
Think this is reasonable, do you think these should be separate repos or just kept as part of this one? Also, for the migration command however, would it be strange to have to explain |
Beta Was this translation helpful? Give feedback.
-
Something that has come up several times in recent discussions with users and contributors is the question of whether Tuist is doing too much. I've had this in my head for quite a while and I'd like to share with you the direction I think we should take with the tool.
First of all, I agree doing too much is not good for Tuist. First, it confuses users. Is it a project generator? Is it yet another Fastlane? The breadth of the tool also makes maintenance harder because more silos appear. In fact, we are starting to suffer from this. This is not necessarily a bad thing as long as the features that are adding bring value and are something that aligns with the direction of the tool. In this regard, the work that @andreacipriani has done to bring insights about how people use the tool is very useful because it'll allow us to say yes or no to maintaining and improving certain features.
That being said, we can't build everything developers need. However, we can build a foundation upon which developers can build and share new workflows and project transformations. Fastlane is a good example of is, they provide developers with utilities and the concept of lanes that they can use to design their workflows. Ruby on Rails does something similar. They provide foundational concepts and frameworks such as the MVC approach to build web apps and the ActiveRecord ORM, and several points of extension for users to build their workflows and customize their app. Shopify would not have been able to succeed with Rails if the framework wouldn't have been so extensible.
Third-party APIs
User mappers
This hasn't been implemented yet, but being able to bring your own mappers would allow users to run validations, and use the in-memory XcodeProj representation to make changes to Xcode projects before they are written o disk. The latter would prevent us from having to add APIs for every single XcodeProj attribute. I think our APIs should cover the most common and required attributes, for example,
sources
,resources
, andinfoPlist
, and let the users extend their final XcodeProj as needed.Tasks.swift
We can provide users with a new manifest,
Tasks.swift
for developers to implement their own workflows in the same way they'd do with Fastlane and lanes. Unlike other manifest files that we serialize through a JSON representation, we could executeTasks.swift
directly as amain.swift
file:Plugins
Plugins are our way to make those extensions shareable across repositories. For now, it only supports project description helpers, but I think we should extend it to support mappers and tasks. That would allow us to extract some of Tuist's commands like
tuist dump
ortuist lint
into a separate repository and let developers add it to their projects if they need it.Suggestions for deprecations
I'd suggest deprecating the following elements:
tuist up
: Although developers are leveraging it, I feel it's very much out of the scope of Tuist. It's not much maintenance work, but it's not aligned with this vision for Tuist.tuist secret
: This command is barely used so there's no need for us to keep maintaining it.Suggestions for being part of a plugin
Once we have support for
Tasks.swift
, we can extract the following commands into plugins:tuist migration
.tuist lint
.tuist graph
tuist doc
Final words
I think our role as contributors and maintainers should be evolving the graph, ensuring the project generation is fast and deterministic, and maintain and improve the following workflows that are common across all the projects: generate, focus, build, test, and release. If we evolve Tuist to be an extensible platform, third-party developers will bring more diversity of ideas through plugins, more developers will be excited to use Tuist, and we maintainers and contributors can focus on the graph and optimizations like focused projects and caching.
Beta Was this translation helpful? Give feedback.
All reactions