Generate Flutter framework swift package#181578
Conversation
|
This pull request was opened from and to a release candidate branch. This should only be done as part of the official Flutter release process. If you are attempting to make a regular contribution to the Flutter project, please close this PR and follow the instructions at Tree Hygiene for detailed instructions on contributing to Flutter. Reviewers: Use caution before merging pull requests to release branches. Ensure the proper procedure has been followed. |
There was a problem hiding this comment.
Code Review
This pull request introduces the generation of a placeholder Swift package named FlutterFramework to facilitate plugin dependencies before a broader change lands in stable. It includes a new constant for the framework's name, updates to the SwiftPackageManager to create this package, and corresponding changes in XcodeBasedProject and various test files to support and verify this new functionality. The changes are well-tested and align with the stated goal of providing a temporary solution for Swift Package Manager integration.
| /// dependencies on Flutter plugin swift packages. | ||
| const kFlutterGeneratedPluginSwiftPackageName = 'FlutterGeneratedPluginSwiftPackage'; | ||
|
|
||
| /// The name of the Swift pacakge that's generated by the Flutter tool to add |
|
|
||
| @override | ||
| Directory get flutterFrameworkSwiftPackageDirectory => | ||
| relativeSwiftPackagesDirectory.childDirectory('FlutterFramework'); |
There was a problem hiding this comment.
For consistency and to avoid magic strings, it's best to use the kFlutterGeneratedFrameworkSwiftPackageTargetName constant here, as it was introduced specifically for this purpose. This adheres to the style guide's principle of "Avoid duplicating state" (Repository Style Guide, line 30).
| relativeSwiftPackagesDirectory.childDirectory('FlutterFramework'); | |
| relativeSwiftPackagesDirectory.childDirectory(kFlutterGeneratedFrameworkSwiftPackageTargetName); |
|
|
||
| @override | ||
| Directory get flutterFrameworkSwiftPackageDirectory => | ||
| relativeSwiftPackagesDirectory.childDirectory('FlutterFramework'); |
There was a problem hiding this comment.
Similar to the FakeMacOSProject, please use the kFlutterGeneratedFrameworkSwiftPackageTargetName constant instead of the hardcoded string "FlutterFramework" for better maintainability and to avoid duplicating state (Repository Style Guide, line 30).
| relativeSwiftPackagesDirectory.childDirectory('FlutterFramework'); | |
| relativeSwiftPackagesDirectory.childDirectory(kFlutterGeneratedFrameworkSwiftPackageTargetName); |
| import PackageDescription | ||
|
|
||
| let package = Package( | ||
| name: "FlutterFramework", |
There was a problem hiding this comment.
To maintain consistency and avoid magic strings, please use the kFlutterGeneratedFrameworkSwiftPackageTargetName constant here. This aligns with the style guide's principle of "Avoid duplicating state" (Repository Style Guide, line 30).
| name: "FlutterFramework", | |
| name: kFlutterGeneratedFrameworkSwiftPackageTargetName, |
| $supportedPlatform | ||
| ], | ||
| products: [ | ||
| .library(name: "FlutterFramework", targets: ["FlutterFramework"]) |
There was a problem hiding this comment.
Please use the kFlutterGeneratedFrameworkSwiftPackageTargetName constant for the product name and target name to ensure consistency and reduce hardcoded values. This adheres to the style guide's principle of "Avoid duplicating state" (Repository Style Guide, line 30).
| .library(name: "FlutterFramework", targets: ["FlutterFramework"]) | |
| .library(name: kFlutterGeneratedFrameworkSwiftPackageTargetName, targets: <String>[kFlutterGeneratedFrameworkSwiftPackageTargetName]) |
| ], | ||
| targets: [ | ||
| .target( | ||
| name: "FlutterFramework" |
There was a problem hiding this comment.
The target name should also use the kFlutterGeneratedFrameworkSwiftPackageTargetName constant for consistency and to avoid hardcoded strings. This aligns with the style guide's principle of "Avoid duplicating state" (Repository Style Guide, line 30).
| name: "FlutterFramework" | |
| name: kFlutterGeneratedFrameworkSwiftPackageTargetName |
| .childDirectory('FlutterFramework') | ||
| .childFile('FlutterFramework.swift'); |
There was a problem hiding this comment.
Using the kFlutterGeneratedFrameworkSwiftPackageTargetName constant here would improve maintainability and consistency, as it avoids hardcoding the directory and file names. This adheres to the style guide's principle of "Avoid duplicating state" (Repository Style Guide, line 30).
| .childDirectory('FlutterFramework') | |
| .childFile('FlutterFramework.swift'); | |
| .childDirectory(kFlutterGeneratedFrameworkSwiftPackageTargetName) | |
| .childFile('${kFlutterGeneratedFrameworkSwiftPackageTargetName}.swift'); |
|
|
||
| @override | ||
| Directory get flutterFrameworkSwiftPackageDirectory => | ||
| relativeSwiftPackagesDirectory.childDirectory('FlutterFramework'); |
There was a problem hiding this comment.
Please use the kFlutterGeneratedFrameworkSwiftPackageTargetName constant instead of the hardcoded string "FlutterFramework" for consistency and better maintainability. This aligns with the style guide's principle of "Avoid duplicating state" (Repository Style Guide, line 30).
| relativeSwiftPackagesDirectory.childDirectory('FlutterFramework'); | |
| relativeSwiftPackagesDirectory.childDirectory(kFlutterGeneratedFrameworkSwiftPackageTargetName); |
| '.package(name: "FlutterFramework", path: "../FlutterFramework")'; | ||
| const targetDependency = |
There was a problem hiding this comment.
It's recommended to use the kFlutterGeneratedFrameworkSwiftPackageTargetName constant for the package and target names to ensure consistency and avoid hardcoded strings. This adheres to the style guide's principle of "Avoid duplicating state" (Repository Style Guide, line 30).
| '.package(name: "FlutterFramework", path: "../FlutterFramework")'; | |
| const targetDependency = | |
| '.package(name: "${kFlutterGeneratedFrameworkSwiftPackageTargetName}", path: "../${kFlutterGeneratedFrameworkSwiftPackageTargetName}")'; | |
| const targetDependency = | |
| '.product(name: "${kFlutterGeneratedFrameworkSwiftPackageTargetName}", package: "${kFlutterGeneratedFrameworkSwiftPackageTargetName}")'; |
|
All the gemini comments are about using hardcoded values in tests and a typo in a comment. I'm going to let that slide as not to have to re-run the tests |
FWIW I strongly disagree with Gemini about not using hard-coded values for at least the part where the test is checking for expected Package.swift contents; if someone changes the constant, the tests should absolutely break, because what we want to test is not "the output matches the constant" it's "the output matches the value we are telling the entire ecosystem to depend on". |
37f698a
into
flutter:flutter-3.41-candidate.0
This PR creates a FlutterFramework swift package with no real content. This is a placeholder so that plugins may add a dependency on the FlutterFramework in their Package.swift before flutter#178931 lands in stable. See go/swiftpm-flutter-release. Impacted Users: Flutter iOS with SwiftPM feature flag enabled Impact Description: Allows plugins to add a dependency on the FlutterFramework in their Package.swift. Workaround: See Problem 2 alternatives in [go/swiftpm-flutter-release](http://goto.google.com/swiftpm-flutter-release) Risk: This PR by itself is low risk. It just generates a couple files in an ephemeral directory. It only is actually used if a plugin adds a dependency on it in it's Package.swift. If a plugin does this, it's still low risk since it's basically just an empty Swift package. It's also behind a feature flag (`flutter config --enable-swift-package-manager`), which can be disabled. Test Coverage: Yes Validation Steps: - `flutter config --enable-swift-package-manager` - `flutter create my_plugin && cd my_plugin/example` - Add `FlutterFramework` to Package.swift (see [example](https://github.com/flutter/flutter/blob/master/packages/integration_test/ios/integration_test/Package.swift#L15-L21)) - `flutter build ios` **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.
This PR creates a FlutterFramework swift package with no real content. This is a placeholder so that plugins may add a dependency on the FlutterFramework in their Package.swift before #178931 lands in stable. See go/swiftpm-flutter-release.
Impacted Users: Flutter iOS with SwiftPM feature flag enabled
Impact Description: Allows plugins to add a dependency on the FlutterFramework in their Package.swift.
Workaround: See Problem 2 alternatives in go/swiftpm-flutter-release
Risk: This PR by itself is low risk. It just generates a couple files in an ephemeral directory. It only is actually used if a plugin adds a dependency on it in it's Package.swift. If a plugin does this, it's still low risk since it's basically just an empty Swift package. It's also behind a feature flag (
flutter config --enable-swift-package-manager), which can be disabled.Test Coverage: Yes
Validation Steps:
flutter config --enable-swift-package-managerflutter create my_plugin && cd my_plugin/exampleFlutterFrameworkto Package.swift (see example)flutter build iosPre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.