Multiple commands in the Flutter plugin tool have arguments that accepts a list of strings or a list of YAML files that contain a list of strings. This introduces a `getYamlListArg` helper so that this logic doesn't need to be duplicated multiple times.
In a subsequent pull requests, this will be used to add a list of packages that are allowed to have Xcode warnings. This will be used by the google_sign_in_ios package which will have warnings when using SwiftPM.
Part of: https://github.com/flutter/flutter/issues/146904
This PR fixes a couple of issues that have popped up in the CI of the tree in the last couple of days:
1. Disables some Android video_player tests that require network access.
2. Fixes our internal tool after a breaking change was made in an upstream dependency.
## Issues
* Mitigates https://github.com/flutter/flutter/issues/160797
* Fixes https://github.com/flutter/flutter/issues/160799
Imports https://github.com/dnfield/flutter_svg into this repository,
with history, and updates it to follow repository conventions:
- Updates min SDKs.
- Removes analysis options and fixes resulting warnings.
- Autoformats.
- Updates pubspecs to follow repo standard.
- Updates repo tooling to allow the `flutter_svg_test` non-dev
dependency on `flutter_test`.
- Adds repo metadata.
- Adds METADATA files.
- Bumps versions and slightly relax version constraints for
vector_graphics* to allow the new versions.
Imports https://github.com/dnfield/flutter_svg into this repository,
with history, and updates it to follow repository conventions:
- Updates min SDKs.
- Removes analysis options and fixes resulting warnings.
- Autoformats.
- Updates pubspecs to follow repo standard.
- Updates repo tooling to allow the `flutter_svg_test` non-dev
dependency on `flutter_test`.
- Adds repo metadata.
- Adds METADATA files.
- Adds commemoration to README.
- Updates example app Android build files to current standards.
- Bumps versions and slightly relax version constraints for
vector_graphics* to allow the new versions.
- Moves gitignore of golden test diffs into the package.
- Add missing licence headers.
- Remove analysis options fix new warnings.
- Update min SDKs.
- Autoformat.
- Update pubspecs to follow repo standard.
- Includes removing dependency overrides for inter-package path
pinning as a default state; this can be added temporarily in PRs
with repo tooling.
- Allow xml dependency, and relax the pinning requirement to allow an
explicit, inclusive-endpoint range.
- Skip tests on unsupported platforms.
- Switch vector_graphics_codec from flutter_test to test.
- Add repo metadata.
- Add commemoration to the README.
- Add AUTHORS files.
- Bump versions and slightly relax version constraints to allow the new
versions.
In part of the documentation, Flutter is spelled out with a typo. I fixed it using a repository search.
- [] The title of the PR starts with the name of the package surrounded by square brackets, e.g. `[shared_preferences]`
Updates all links to the Flutter wiki to point to their new location in the flutter/flutter repository. (The sole exception is a link to a doc that doesn't have a final home yet, and is linked from legacy code anyway so doesn't really need to be updated.)
While touching the PR template, makes a few minor improvements:
- Removes the breaking change discussion that doesn't apply to this repository, as breaking changes are handled totally differently for packages (and is covered by the link to docs about Dart versioning).
- Adds text and a link to reflect the fact that some PRs can be changelog-exempt.
- Adds `build_runner`, `mockito`, and `pigeon` to the list of dependencies that we expect to only be in dev_dependencies.
- Fixes the error message for violations; I had missed in initial review that the errorr message was the same as the one for non-repo-local depndencies, making it misleading about what the problem was and how to fix it. (Also fixed the indentation, which had always been wrong.)
- Fixes `camera_avfoundation`, which had a violation introduced in my recent PR to start the Pigeon conversion.
See https://github.com/flutter/flutter/issues/117905
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
Additional checks as a followup to https://github.com/flutter/packages/pull/6446
*List which issues are fixed by this PR. You must list at least one issue.*
Related to https://github.com/flutter/flutter/issues/145992
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
Create a linter that ensures that `integration_test` is not used in dependencies.
Will be paired with a change to documentation
```
If you are considering adding an external dependency:
Consider other options, and discuss with #hackers-ecosystem in Discord.
* If you add a dev_dependency on an external package, pin it to a specific version if at all possible.
* If you add a dependency on an external package in an example/, pin it to a specific version if at all possible.
* Some dependencies should only be linked as dev dependencies like integration_test
```
Related to flutter/flutter/issues/145992
Adds [topics](https://dart.dev/tools/pub/pubspec#topics) to all
packages, supporting the new pub feature for categorizing packages. The
heuristics I used were:
- Try to use existing topics from https://pub.dev/topics where
applicable
- Add new topics as necessary to cover things that seemed like obvious
relevant topics
- Include the plugin name as a topic for all federated plugin packages,
for grouping (since pub doesn't inherently group or cross-link
implementations)
This is not an attempt to be exhaustive; as topics evolve I expect we
will add more or adjust.
Also updates the repo tooling to enforce topics, so that we don't forget
to add them to new packages. The enforced rule is:
- All packages must have at least one topic. We could potentially change
this to allow an empty `topics` section so that we are enforcing that we
didn't just forget to add the section, but in practice even for packages
that we don't expect people to be likely to use, I didn't have any issue
coming up with at least one relevant topic.
- Federated plugin packages must contain the plugin name as a topic.
While this isn't time-critical, I chose to include version bumps so that
we aren't rolling out topics in a piecemeal way (e.g., with only a
random subset of a federated plugin's packages having topics on pub.dev
based on what has happened to have a bugfix).
Refactors colorization to a centralized utility file, and makes it all conditional on `stdout` having ANSI escape support. This makes the output more readable on LUCI, which unlike the Cirrus log display doesn't handle ANSI.
Fixes https://github.com/flutter/flutter/issues/89392
Since the tool only needs to support back to Flutter 3.3 (the oldest version we still run CI with), this updates the tool to the corresponding minimum Dart version.
This allows the use of `super` parameters, so `dart fix --apply` was run to convert them all (and remove all the includes that were only needed for setting default values).
Also opportunistically cleans up a bunch of unnecessary, very old `dart:async` includes. (Other than those removals, the changes here are all `dart fix`-generated.)
Adds aliases for all commands that put the verb first, since currently they are inconsistent which can make it hard to remember (in particular, I often write `check-foo` instead of `foo-check` when running locally, and it fails).
Also does the long-overdue renaming of `test` to `dart-test`, since we now have `native-test`, `custom-test`, etc. `test` continues to work as an alias for individual muscle memory.
As described in https://github.com/flutter/flutter/issues/121684, we currently have inconsistencies between Flutter SDK constraints and Dart SDK constraints; we have often updated only the former. This PR:
1. Adds CI enforcement via the repo tooling that the minimum versions are consistent.
2. Adds a new repo tooling command to update SDK constraints, to help mass-fix all the violations of the new enforcement in step 1 (and for future mass changes, such as when we update our test matrix and mass-drop support for versions that are no longe tested).
- In all cases, the looser constraint was updated to match the more restrictive constraint, such that there's no actual change in what Flutter version any package actually supports.
3. Runs `dart fix --apply` over all changed packages to automatically fix all of the analysis failures caused by step 2 suddenly making all of our packages able to use `super` parameters.
Fixes https://github.com/flutter/flutter/issues/121684
Fixes https://github.com/flutter/flutter/issues/121685
Updates links and references to `flutter/plugins` to use `flutter/packages` instead, including making the `repository` pubspec.yaml check stricter in the repo tooling to ensure all packages are pointing to the right place.
Exceptions to the updates are:
- Changelog entries.
- Links to pull requests.
This will re-publish all the moved plugins, thus fixing the current redness of `release` (due to the current versions not being tagged in this repository).
Adds options to `pubspec.yaml` to check that the minimum supported SDK range for Flutter/Dart is at least a given version, to add CI enforcement that we're updating all of our support claims when we update our tested versions (rather than it being something we have to remember to do), and enables it in CI.
As part of enabling it, fixes some violations:
- path_provider_foundation had been temporarily dropped back to 2.10 as part of pushing out a regression fix.
- a number of examples were missing Flutter constraints even though they used Flutter.
- the non-Flutter `plugin_platform_interface` package hadn't been update since I hadn't thought about Dart-only constraints in the past.
The analysis options have gotten behind; this re-syncs to the current state of flutter/flutter. For options that are non-trivial to enable, either because they are non-trivial to fix, or touch a very large number of files, they are locally disabled with clear "LOCAL CHANGE" markers so that it's obvious where we are out of sync. For options that are simple to resolve, they are enabled in the PR.
Part of https://github.com/flutter/flutter/issues/76229
The repository check always failed when run on Windows, because the
relative path generated to check the end of the URL was using local
filesystem style for separators, but URLs always use POSIX separators.
pub.dev deducts points for having a pubspec.yaml `description` that is too short or too long; several of our plugins are losing points on this. To ensure that we are following—and modeling—best practices, this adds a check that our `description` fields meet pub.dev expectations.
Fixes our existing violations. Two are not published even though this only takes effect once published:
- camera: We change this plugin pretty frequently, so this should go out soon without adding a release just for this trivial issue.
- wifi_info_flutter: This is deprecated, so we don't plan to release it. It has to be fixed to allow the tool change to land though.
Creates a new command to validate that PRs don't change platform interface packages and implementations at the same time, to try to prevent ecosystem-breaking changes. See https://github.com/flutter/flutter/issues/89518 for context.
Per the explanation in the issue, this has carve-outs for:
- Changes to platform interfaces that aren't published (allowing for past uses cases such as making a substantive change to an implementation, and making minor adjustments to comments in the PI package based on those changes).
- Things that look like bulk changes (e.g., a mass change to account for a new lint rule)
Fixes https://github.com/flutter/flutter/issues/89518
Packages are the primary conceptual object in the tool, but currently they are represented simply as Directory (or occasionally a path string). This introduces an object for packages and:
- moves a number of existing utility methods into it
- sweeps the code for the obvious cases of using `Directory` to represent a package, especially in method signatures and migrates them
- notes a few places where we should migrate later, to avoid ballooning the size of the PR
There are no doubt other cases not caught in the sweep, but this gives us a foundation both for new code, and to migrate incrementally toward as we find existing code that was missed.
Ensures that the full relative path in the 'repository' link is correct,
not just the last segment. This ensure that path-level errors (e.g.,
linking to the group directory rather than the package itself for
app-facing packages) are caught.
Also fixes the errors that this improved check catches, including
several cases where a previously unfederated package wasn't fixed when
it was moved to a subdirectory.
The federated plugin spec calls for implementation packages to include an `implements` entry in the `plugins` section of the `pubspec.yaml` indicating what app-facing package it implements. Most of the described behaviors of the `flutter` tool aren't implemented yet, and the pub.dev features have `default_plugin` as a backstop, so we haven't noticed that they are mostly missing (or in one case, incorrect).
To better future-proof the plugins, and to provide a better example to people looking at our plugins as examples of federation, this adds a CI check to make sure that we are correctly adding it, and fixes all of the missing/incorrect values it turned up.
Fixes https://github.com/flutter/flutter/issues/88222
The purpose of this PR is to make running all unit tests on Windows pass (vs failing a large portion of the tests as currently happens). This does not mean that the commands actually work when run on Windows, or that Windows support is tested, only that it's possible to actually run the tests themselves. This is prep for actually supporting parts of the tool on Windows in future PRs.
Major changes:
- Make the tests significantly more hermetic:
- Make almost all tools take a `Platform` constructor argument that can be used to inject a mock platform to control what OS the command acts like it is running on under test.
- Add a path `Context` object to the base command, whose style matches the `Platform`, and use that almost everywhere instead of the top-level `path` functions.
- In cases where Posix behavior is always required (such as parsing `git` output), explicitly use the `posix` context object for `path` functions.
- Start laying the groundwork for actual Windows support:
- Replace all uses of `flutter` as a command with a getter that returns `flutter` or `flutter.bat` as appropriate.
- For user messages that include relative paths, use a helper that always uses Posix-style relative paths for consistent output.
This bumps the version since quite a few changes have built up, and having a cut point before starting to make more changes to the commands to support Windows seems like a good idea.
Part of https://github.com/flutter/flutter/issues/86113
Add a summary to the end of successful runs for everything using the new looping base command, similar to what we do for summarizing failures. This will make it easy to manually check results for PRs that we know should be changing the set of run packages (adding a new package, adding a new test type to a package, adding a new test type to the tool), as well as spot-checking when we see unexpected results (e.g., looking back and why a PR didn't fail CI when we discover that it should have).
To support better surfacing skips, this restructures the return value of `runForPackage` to have "skip" as one of the options. As a result of it being a return value, packages that used `printSkip` to indicate that *parts* of the command were being skipped have been changed to no longer do that.
Fixes https://github.com/flutter/flutter/issues/85626
Combines the two different aspects of version-checking into a single looping structure based on plugins, using the new base command, rather than one operating on plugins as controlled by the usual flags and the other operating on a git list of changed files.
Also simplifies the determination of the new version by simply checking the file, rather than querying git for the HEAD state of the file. Tests setup is simplified since we no longer need to set up nearly as much fake `git` output.
Minor changes to base commands:
- Move indentation up to PackageLoopingCommand so that it is consistent across commands
- Add a new post-loop command for any cleanup, which is needed by version-check
- Change the way the GitDir instance is managed by the base PluginCommand, so that it's always cached even when not overridden, to reduce duplicate work and code.
Part of https://github.com/flutter/flutter/issues/83413
Most of our commands are generally of the form:
```
for (each plugin as defined by the tool flags)
check some things for success or failure
print a summary all of the failing things
exit non-zero if anything failed
```
Currently all that logic not consistent, having been at various points copied and pasted around, modified, in some cases rewritten. There's unnecessary boilerplate in each new command, and there's unnecessary variation that makes it harder both to maintain the tool, and to consume the test output:
- There's no standard format for separating each plugin's run to search within a log
- There's no standard format for the summary at the end
- In some cases commands have been written to ToolExit on failure, which means we don't actually get the rest of the runs
This makes a new base class for commands that follow this structure to use, with shared code for all the common bits. This makes it harder to accidentally write new commands incorrectly, easier to maintain the code, and lets us standardize output so that searching within large logs will be easier.
This ports two commands over as a proof of concept to demonstrate that it works; more will be converted in follow-ups.
Related to https://github.com/flutter/flutter/issues/83413
common.dart is a large-and-growing file containing all shared code,
which makes it hard to navigate. To make maintenance easier, this splits
the file (and its test file) into separate files for each major
component or category.
- Replaces most explicit use of `fileSystem` with path construction using the `child*` utility methods
- Removes explicit passing of a filesystem to the commands; we're already passing a `Directory` for the
root where the tool operates, and we should never be using a different filesystem than that directory's
filesystem, so passing it was both redundant, and a potential source of test bugs.
