Repository navigation
Exclude local Swift package schemes from --flavor error message - #191098
auto-submit[bot] merged 52 commits into
Conversation
XcodeProjectInfo already filters remote Swift package checkout schemes and Flutter plugin schemes out of the scheme list shown when a developer passes an invalid --flavor, but it did not account for local Swift packages referenced directly from the host project's project.pbxproj (XCLocalSwiftPackageReference). Xcode auto-merges those packages' own schemes into the project's scheme list the same way it does for remote checkouts, so they were leaking into the 'available schemes' error message as if they were valid flavors. This parses XCLocalSwiftPackageReference entries out of project.pbxproj, resolves each relativePath against the host app root, and adds any schemes found under that package's .swiftpm/xcode/xcshareddata/xcschemes directory to the ignore set — mirroring the existing logic for remote checkouts, which is now shared via a small helper. Fixes flutter#190098
There was a problem hiding this comment.
Code Review
This pull request introduces support for identifying and filtering local Swift package schemes in Xcode projects by parsing XCLocalSwiftPackageReference blocks within the project.pbxproj file, refactoring the scheme extraction logic into a shared helper method, and adding corresponding unit tests. The review feedback suggests making the regular expression for parsing these references more robust to accommodate other properties that Xcode may insert between fields, and updating the unit tests to verify this behavior.
Address gemini-code-assist review feedback: relativePath does not necessarily immediately follow isa = XCLocalSwiftPackageReference; in project.pbxproj, since Xcode may insert other properties (e.g. name, customName) in between. Widen the match to allow any fields before relativePath within the same object body, and add a customName field to the regression test's fixture to cover this.
|
This pull request targets the Please change the base branch of this pull request to |
|
Hi @okorohelijah, just following up on this PR when you get a chance to take a look. All checks have passed and @vashworth has already approved the changes. Since this requires a second review before |
When a developer mistypes a
--flavor(e.g.flutter build ios --flavor Prdo), Flutter reports the available schemes so they can pick a valid one:XcodeProjectInfoalready filters two kinds of non-flavor schemes out of this list: Flutter's own generated SwiftPM packages, and remote Swift package checkouts (packages fetched by SwiftPM into the build directory'scheckoutsfolder). Xcode auto-merges each of those packages' own.xcschemefiles into the host project's scheme list, even though they aren't declared in the host.xcodeprojand aren't real Flutter flavors.What wasn't handled: local Swift packages — ones added directly to the Xcode project (an
XCLocalSwiftPackageReferenceinproject.pbxproj, e.g. living insideios/) rather than fetched as a remote dependency. Those never appear under thecheckoutsdirectory, so their auto-merged schemes leaked straight through intodefinesCustomSchemes/schemes, and ended up quoted in the error message as if they were valid--flavorvalues.This PR parses
XCLocalSwiftPackageReferenceentries out ofproject.pbxproj, resolves each entry'srelativePathagainst the host app root, and — for any local package that ships its own.swiftpm/xcode/xcshareddata/xcschemes/directory — adds those scheme names to the same ignore set used for remote checkouts. The scheme-directory scan itself was already duplicated between the (new) local-package path and the existing remote-checkout path, so it's factored into one small shared helper.Fixes #190098
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.