Make WorkspaceSettings initializer public
#658
Conversation
Codecov Report
@@ Coverage Diff @@
## main #658 +/- ##
==========================================
+ Coverage 84.66% 84.75% +0.08%
==========================================
Files 154 157 +3
Lines 8878 8987 +109
==========================================
+ Hits 7517 7617 +100
- Misses 1361 1370 +9
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Thanks for submitting this @jakeatoms !
This PR exposes the initializer of WorkspaceSettings, so we can use it in Tuist.
π
It also makes the autoCreateSchemes a non-optional boolean.
This is sadly a breaking change π - I'm curious as to the motivation for this change?
Within XcodeProj nil is a valid value and implies not writing the corresponding attributes to the underlying files and letting Xcode pick an appropriate default.
Taking a quick look at the .xcsettings files created by Xcode, the IDEWorkspaceSharedSettings_AutocreateContextsIfNeeded property is indeed optional, as Xcode will not include this by default. As such XcodeProj needs to be able to handle cases where it's missing and also ensure it can omit writing this property too.
Thinking ahead for the changes in Tuist, we'll need to make sure to only create the .xcsettings file and update the corresponding properties when needed (i.e. when we need to explicitly disable the default behaviour), otherwise we'd skip writing this file / or property all together.
| /// Path to workspace DerivedData directory. | ||
| public var derivedDataCustomLocation: String? | ||
|
|
||
| /// When true, Xcode auto-creates schemes in the project. | ||
| public var autoCreateSchemes: Bool? | ||
| public var autoCreateSchemes: Bool |
There was a problem hiding this comment.
This is sadly a breaking change π
My goal was a better user API, but I was mostly focused on just the property I'm implementing in Tuist. The Descripter would be optional, so if the user didn't set it, it would not create the file. However, your point is well taken because if we implement additional properties in the future, we don't want to write this property as well, if the user wants the default behavior. That leads me to think that my Tuist implementation of this should be with an enum that defaults to |
| let buildSystem = BuildSystem(rawValue: buildSystemString) | ||
| { |
There was a problem hiding this comment.
This formatting we done by the Rake task
jakeatoms
changed the title
WorkspaceSettings.autoCreateSchemes and make initializer publicWorkspaceSettings initializer public
jakeatoms
changed the title
WorkspaceSettings initializer publicWorkspaceSettings initializer public
|
@all-contributors add @jakeatoms for code |
|
I've put up a pull request to add @jakeatoms! π |
|
@jakeatoms I've released a new version of XcodeProj that includes your changes, 8.7.1 |
Resolves #657
Short description π
This PR exposes the initializer of
WorkspaceSettings, so we can use it inTuist.It also makes theautoCreateSchemesa non-optional boolean.Solution π¦
I'm working on this Tuist issue: tuist/tuist#3487
The gist is that when a project specifies its own schemes, Xcode begins to nag when the workspace is opened. I'm working on the related Tuist PR, but before I can proceed, I need to be able to initialize this type.
I also think that optional booleans are a source of confusion as their behavior is ambiguous. Making it required will provide a clear behavior to the consumer and have a concrete result.Implementation π©βπ»π¨βπ»
public.