Replies: 2 comments 4 replies
-
👋🏼 Thanks for making this proposal @olejnjak and capturing the motivation behind this change. While adding a new option to So here's my proposal. Instead of adding a new option, we'll take the opportunity that we are working on 2.0 to introduce a breaking change here.
enum SchemeGenerationOption {
case targetsScheme
case projectScheme
case all
}
This solution is in line with Deprecating global project attributes in favour of helpers, and I believe it's more intuitive for users. |
Beta Was this translation helpful? Give feedback.
-
I'd be curious to get also opinions from @tuist/core |
Beta Was this translation helpful? Give feedback.
-
Need/problem
I would love to make sure that we can keep project scheme in workspace even when using
disableAutogeneratedSchemes
option inConfig
.Motivation
In my project, I have dozens of targets (app, widget, extensions, bunch of frameworks, its testing frameworks and unit test target for each framework). This means I have bunch of autogenerated schemes, I consider many of them unnecessary (at least schemes for test targets, maybe even schemes for testing frameworks), but this discussion is not the point of this RFC.
If I want to get rid of those unnecessary schemes, I have to use the above mentioned generation option which will automatically remove the project scheme and I think this scheme is pretty useful.
Detailed design
My suggested solution in #3364 is adding
disableProjectScheme
generation option and updatingWorkspaceMapperProvider
to use this option instead ofdisableAutogeneratedSchemes
Drawbacks
I think the only drawback is that current projects that use
disableAutogeneratedSchemes
will now contain project scheme when they generate project. They will need to add this new option to theirConfig
.Alternatives
I can imagine another solution that would mean that instead of disabling the scheme, we could make project scheme easier to
add when using
disableAutogeneratedSchemes
. Not sure about implementation of this idea.Or maybe even the easiest solution might be to always generate project scheme. I think for most manifests it will be one extra scheme.
Adoption strategy
I'd say it is breaking even though there would be no compilation issue of current manifests, but current manifests might experience that project scheme is suddenly added - which might be also wanted side-effect.
How we teach this
Just adding new case to
Config.GenerationOptions
is simple without any major impact to documentation.Beta Was this translation helpful? Give feedback.
All reactions