refactor: strongly typed values in BuildSettings and BuildFileSettings
#903
Conversation
waltflanagan
changed the title
waltflanagan
changed the title
BuildSettings and BuildFileSettings
The settings here are constrained to two cases, one as a string and one as a string array as defined here: https://buck.build/javadoc/com/facebook/buck/apple/xcode/xcodeproj/PBXBuildFile.html Given the narrow use case we should constraint the available types here to fit the need.
waltflanagan
force-pushed
the
waltflanagan/StrongTypes
branch
from
46ac0d6 to
791afe0
Compare
waltflanagan
force-pushed
the
waltflanagan/StrongTypes
branch
from
a28c2ff to
bf96639
Compare
- Updates to xcdiff for compatibility with tuist/XcodeProj#903 - Build setting values are no longer type erased and instead can now either be a `String` or `[String]` - This alleviates the need to casting values and throwing errors when dealing with build settings Test Plan: - Verify CI passes Signed-off-by: Kassem Wridan <[email protected]>
There was a problem hiding this comment.
Thanks @waltflanagan this is a much needed change! 👌
Indeed this is source breaking and would likely need a major release
e.g. updates needed for xcdiff bloomberg/xcdiff#145
| // func XCTAssertEqual(_ lhs: BuildSettings, _ rhs: BuildSettings, file: StaticString = #file, line: UInt = #line) { | ||
| // XCTAssertEqual(lhs as NSDictionary, | ||
| // rhs as NSDictionary, | ||
| // file: file, | ||
| // line: line) | ||
| // } |
|
@kwridan thats what i was afraid of. I'll see if i can find some time to put together a 9.0 checklist so we can identify anything else that we may want to break There are some other Do you think it would be worth a transitional phase that preserves |
|
I wouldn't shy away from a a major release for this per se as there are already a few compatibility APIs lying around that could do with a clean up: e.g. You are right, there are other collections (e.g. Another accessor could be exposed with the strong types |
XcodeGen introduced the ability to include whole `PBXObject` values within these dictionaries which end up being written to the project as their reference string value. In order to simplify the attributes interface, i’m removing that capability and consumers will need to do their own unwrapping.
| for (reference, value) in targetAttributeReferences { | ||
| plistTargetAttributes[reference.value] = value.mapValues { value in | ||
| (value as? PBXObject)?.reference.value ?? value |
There was a problem hiding this comment.
This was added as a feature for XcodeGen to be able to easily work with these values. This complicates support for strong types though and the migration due to the removal of this change would be to set the .string(object.reference.value) instead of just object at the callsites.
Short description 📝
Mostly work that was done on the
9.0.0branch that shouldn't be coupled to Sendability changes.This introduces the
BuildSettingtype that will allow safer manipulation of build settings and set us with more typesafety when working with build settings that have constraints.Keys issues are that this introduces source breaking changes with the signature of the
BuildSettingstypealias.