Replies: 3 comments 5 replies
-
|
Hey, those are great new. Are there any plans to also ship the |
Beta Was this translation helpful? Give feedback.
-
|
That's right. You can check the options here |
Beta Was this translation helpful? Give feedback.
-
|
Would like to register for beta testing for Enterprise -> self hosted |
Beta Was this translation helpful? Give feedback.
-
|
I think many would like to be able to add pre or post tuist generate actions. That is, something similar to post_install hook in Cocoapods, based on a graph/installer. Now it is technically possible to do this in the form of an executable tuist plugin/task, with the connection of ProjectAutomation dependency, but the graph does not contain all the properties of the project/target/etc and requires a separate launch |
Beta Was this translation helpful? Give feedback.
-
|
Hey @Ernest0-Production 👋🏼
I'd rather understand what pre-post project modifications are necessary and incorporate them into Tuist itself. If it's a step that doesn't require the project at all, I'd rather suggest to embrace the UNIX philosophy and wrap Tuist in a script, instead of delegating that to the tool, which is an additional piece of functionality that we'd need to maintain. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe I didn't make myself clear. I would like hooks not to modify the graph itself, but to perform additional actions based on the typed project graph. For example, I use swiftgen or any other resource generator (not wanting to use the built-in swiftgen mechanism in the tuist) and I need to pre-generate Now I have solved this problem by creating a separate template for the |
Beta Was this translation helpful? Give feedback.
-
|
I see what you mean now. Thanks for clarifying it @Ernest0-Production. |
Beta Was this translation helpful? Give feedback.
-
|
Equally important will be the ability to generate a template based on parameters. Please read the proposal 🙏 |
Beta Was this translation helpful? Give feedback.
-
Recent work on significant features for Tuist got us thinking it's an excellent opportunity to batch all of them together and cut a significant version, Tuist 4.0. Here are some ideas of features that we'd like to include in the release, and I'm starting a discussion to get everyone else's ideas.
1. Drop support for Carthage via
Dependencies.swiftWe'll remove the integration of Tuist with Carthage via the
Dependencies.swiftinterface and the commandtuist fetchto fetch dependencies. Users will still be able to use Carthage, but they'll have to run Carthage commands before generating projects and referring to the binaries that Carthage generates using binary target dependencies.Rationale: We are narrowing the surface of
Dependencies.swiftdown to Swift Packages, which is already a vast stretch maintenance for us and prone to have a lousy bus factor. We want to support fewer options but better, and aligning with Apple's direction is the path forward.2. Define dependencies via a
Package.swiftWhen we provided our solution for integrating dependencies via
Dependencies.swift, we introduced a new interface to support other package managers like Carthage. We also had CocoaPods in mind, but I'm glad it didn't happen because it'd have been a tremendous amount of support and maintenance load. The caveat with adding a new interface is that we broke the contract with some tools, like those that do dependency analysis or updating (e.g. Dependabot) that depend on having a Package.swift and Package.resolved files. We believe that breaking those workflows is not great, and we'd like to take steps back and adopt Apple's default interface, aPackage.swift. Since we are dropping support for Carthage, we are in a perfect position to execute this work. We also plan to change the internal details of how packages are integrated, but that's more of an implementation detail that we'll execute later.3. Support for Swift Macros
We want to add support for Swift Macros both officially (following Xcode's method) and via our custom integration that's compatible with caching. Thanks to caching, you'll be able to cache the Swift Macros executables, and we'll configure the dependent targets accordingly to execute Swift Macros that have been previously compiled from the same or other environments.
4. Better support for Objective-C Swift Packages
Our custom integration of Swift Packages needs to handle Objective-C scenarios gracefully. This leads to developers having to set build settings manually or even defining module maps themselves. This is not the developer experience we want to provide, so we will do some work to ensure that Swift Packages that contain Objective-C can be integrated with no additional overrides.
5. Multiplatform support
Until now, supporting multiple platforms required defining a per-platform target, which significantly worsened the developer's ergonomics. Xcode supports what they call "platform filters," but we didn't have an API to express those filters. Fortunately, Mike (from Etsy) and Kas (from Tuist's Core Team) are excellently introducing those concepts in our code base and doing the necessary refactors to support multi-platform targets incrementally. Later on, we'll provide APIs to support filtering other target elements such as resources.
6. Tuist Cloud
We'll officially announce Tuist Cloud. This new version of Tuist Cloud is very CLI-first, comes with additional features such as incremental test execution and compilation across environments, and will provide you with a dashboard to better understand your projects and make informed decisions.
7. Drop
tuistenvMaintaining an installer and version enabler ourselves when there are more secure and battle-tested options out there is unnecessary burden that we'd like to get rid of. We'll drop tuistenv and provide a Homebrew official installer. Because Homebrew's version pinning is far from ideal, we'll also provide an asdf plugin. For those of you that don't know it, asdf is a better and more secure version of
tuistenvBeta Was this translation helpful? Give feedback.
All reactions