6d19fa3bfa
This PR adds initial support for Swift Package Manager (SPM). Users must opt in. Only compatible with Xcode 15+. Fixes https://github.com/flutter/flutter/issues/146369. ## Included Features This PR includes the following features: * Enabling SPM via config `flutter config --enable-swift-package-manager` * Disabling SPM via config (will disable for all projects) `flutter config --no-enable-swift-package-manager` * Disabling SPM via pubspec.yaml (will disable for the specific project) ``` flutter: disable-swift-package-manager: true ``` * Migrating existing apps to add SPM integration if using a Flutter plugin with a Package.swift * Generates a Swift Package (named `FlutterGeneratedPluginSwiftPackage`) that handles Flutter SPM-compatible plugin dependencies. Generated package is added to the Xcode project. * Error parsing of common errors that may occur due to using CocoaPods and Swift Package Manager together * Tool will print warnings when using all Swift Package plugins and encourage you to remove CocoaPods This PR also converts `integration_test` and `integration_test_macos` plugins to be both Swift Packages and CocoaPod Pods. ## How it Works The Flutter CLI will generate a Swift Package called `FlutterGeneratedPluginSwiftPackage`, which will have local dependencies on all Swift Package compatible Flutter plugins. The `FlutterGeneratedPluginSwiftPackage` package will be added to the Xcode project via altering of the `project.pbxproj`. In addition, a "Pre-action" script will be added via altering of the `Runner.xcscheme`. This script will invoke the flutter tool to copy the Flutter/FlutterMacOS framework to the `BUILT_PRODUCTS_DIR` directory before the build starts. This is needed because plugins need to be linked to the Flutter framework and fortunately Swift Package Manager automatically uses `BUILT_PRODUCTS_DIR` as a framework search path. CocoaPods will continue to run and be used to support non-Swift Package compatible Flutter plugins. ## Not Included Features It does not include the following (will be added in future PRs): * Create plugin template * Create app template * Add-to-App integration |
||
---|---|---|
.. | ||
bin | ||
doc | ||
gradle | ||
ide_templates/intellij | ||
lib | ||
static | ||
templates | ||
test | ||
tool | ||
analysis_options.yaml | ||
dart_test.yaml | ||
pubspec.yaml | ||
README.md |
Flutter Tools
This section of the Flutter repository contains the command line developer tools for building Flutter applications.
Working on Flutter Tools
Be sure to follow the instructions on CONTRIBUTING.md to set up your development environment. Further, familiarize yourself with the style guide, which we follow.
Setting up
First, ensure that the Dart SDK and other necessary artifacts are available by invoking the Flutter Tools wrapper script. In this directory run:
$ flutter --version
Running the Tool
To run Flutter Tools from source, in this directory run:
$ dart bin/flutter_tools.dart
followed by command-line arguments, as usual.
Running the analyzer
To run the analyzer on Flutter Tools, in this directory run:
$ flutter analyze
Writing tests
As with other parts of the Flutter repository, all changes in behavior must be
tested.
Tests live under the test/
subdirectory.
-
Hermetic unit tests of tool internals go under
test/general.shard
and must run in significantly less than two seconds. -
Tests of tool commands go under
test/commands.shard
. Hermetic tests go under itshermetic/
subdirectory. Non-hermetic tests go under itspermeable
sub-directory. Avoid adding tests here and prefer writing either a unit test or a full integration test. -
Integration tests (e.g. tests that run the tool in a subprocess) go under
test/integration.shard
. -
Slow web-related tests go in the
test/web.shard
directory.
In general, the tests for the code in a file called file.dart
should
go in a file called file_test.dart
in the subdirectory that matches
the behavior of the test.
The dart_test.yaml
file configures the timeout for these tests to be
15 minutes. The test.dart
script that is used in CI overrides this
to two seconds for the test/general.shard
directory, to catch
behaviour that is unexpectedly slow.
Please avoid setting any other timeouts.
Using local engine builds in integration tests
The integration tests can be configured to use a specific local engine
variant by setting the FLUTTER_LOCAL_ENGINE
and FLUTTER_LOCAL_ENGINE_HOST
environment svariable to the name of the local engines (e.g. android_debug_unopt
and host_debug_unopt
). If the local engine build requires a source path, this
can be provided by setting the FLUTTER_LOCAL_ENGINE_SRC_PATH
environment
variable. This second variable is not necessary if the flutter
and engine
checkouts are in adjacent directories.
export FLUTTER_LOCAL_ENGINE=android_debug_unopt
export FLUTTER_LOCAL_ENGINE_HOST=host_debug_unopt
flutter test test/integration.shard/some_test_case
Running the tests
To run all of the unit tests:
$ flutter test test/general.shard
The tests in test/integration.shard
are slower to run than the tests
in test/general.shard
. Depending on your development computer, you
might want to limit concurrency. Generally it is easier to run these
on CI, or to manually verify the behavior you are changing instead of
running the test.
The integration tests also require the FLUTTER_ROOT
environment
variable to be set. The full invocation to run everything might
therefore look something like:
$ export FLUTTER_ROOT=~/path/to/flutter-sdk
$ flutter test --concurrency 1
This may take some time (on the order of an hour). The unit tests alone take much less time (on the order of a minute).
You can run the tests in a specific file, e.g.:
$ flutter test test/general.shard/utils_test.dart
Forcing snapshot regeneration
To force the Flutter Tools snapshot to be regenerated, delete the following files:
$ rm ../../bin/cache/flutter_tools.stamp ../../bin/cache/flutter_tools.snapshot