The instructions for `format` failures still referred to using `activate`, which is no longer how tools are invoked. Replace the specific instructions with a link to the relevant README section to make them evergreen.
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.
Updates `update-excerpts` to support any top-level .md file (other than CHANGELOG.md), rather than just README.md. This is useful for supplemental content, such as migration guides linked from the main README file.
Also makes some small improvements to the error messaging:
- The list of incorrect files is now relative to, and restricted to, the package. This makes the error message simpler, and ensures that changed files in other packages don't get listed.
- Adds a link to the relevant wiki docs, since this has been a source of confusion for newer contributors.
Now that the repo tooling is always run from source, not via `pub global`, we no longer need to infer the repo location from the current directory. Instead, hard-code knowledge of where the repository root is. This makes it much easier to run the tooling, since it's common to be in a package directory rather than the repo root.
To make it even easier to run from within a package, this also adds a `--current-package` as an alternative to `--packages`. This makes it possible to, e.g., write local wrapper scripts that run a specific set of commands on whatever the current package happens to be (such as a generic version of the script discussed in https://github.com/flutter/packages/pull/4129).
As related cleanup, makes the tool non-publishable (we haven't been publishing it since the repo merge, but I never made it unpublishable; this is important now that it would not work if published) and remove the LICENSE and CHANGELOG since it's no longer a stand-alone package.
Fixes https://github.com/flutter/flutter/issues/128231
Fixes https://github.com/flutter/flutter/issues/128232
Currently we are running Dart unit tests in Chrome for any plugin with
web support, but it should only be necessary for plugins that have an
inline web implementation, not for app-facing packages that endorse a
web implementation.
This option had been disabled to match flutter/flutter, but the reason it was disabled there was "too many false positives", mostly around animation. That doesn't apply to most packages here, and we've had a number of production bugsâespecially in plugins, that use async heavily in ways that are intended to be client-awaitableâthat this would have caught.
This PR:
- Enables the option at the repo level.
- Permanently (unless the owners decide to change it) opts out `animations` and `go_router`, both of which looked like mostly or entirely false positives.
- Temporarily opted out a few plugins that have a lot of violations that should be handled in their own PRs later (`camera_android_camerax`, most of `webview_flutter`).
- Fixes all remaining violations.
In many cases this PR is behavior-changing, replacing implicitly unawaited futures that did not seem obviously intentional with `await`ed futures, so non-test code in particular should be reviewed carefully to make sure the changes are correct. All of the changes are manual, not `fix`-generated.
Part of https://github.com/flutter/flutter/issues/127323
Adds the ability to replace portions of the `flutter create`d app with saved copies, and adds a second build-all phase for Android that uses a Flutter 2.0.6-created `android/` directory (AGP 4.1, Gradle 6.7) to catch issues like https://github.com/flutter/flutter/issues/125621 and https://github.com/flutter/flutter/issues/125482 prior to release.
Includes some incidental cleanup:
- Extracts a helper method for adjusting files, so that this doesn't add even more copies of basically identical code.
- (This was motivated by an earlier version of the PR that added modifications to several more files, which I ended up undoing, but the cleanup seemed worth keeping.)
- Adds missing unit test coverage.
- Reworks the unit tests to use a mock process manager and dummy files, instead of each test actually calling `flutter create`, which made each new test add several seconds to the unit test suite.
- While this reduces the integration-style coverage, in practice the integration tests of the repo tooling is the CI itself, so the unit tests should be true unit tests.
- Changes the non-legacy test to Kotlin; we were still testing with Java even though Kotlin has been the default for quite a while, so we weren't testing what most new users would actually be running. Since we now have a legacy test, I used Java there to cover both.
- Removes some dead code for modifying the AndroidManifest.xml; when trying to set up unit tests for it I discovered that it no longer matches anything in an actual project. It dates back to the original command, and seems to have been a camera-related hack, which we clearly no longer need since it wasn't working and camera still works in build-all.
This is captured somewhat in the README in the legacy project directory, but to document the approach here: originally I was going to add flags to change individual items (AGP version, Gradle version), but quickly ran into the fact that selective downgrading is extremely fragile. E.g.,:
- The Kotlin version set in current projects doesn't work when downgrading AGP and Gradle.
- The app template can unconditionally use anything (e.g., `namespace`) that the AGP version it uses supports, so arbitrary future breakage is possible.
It's also less useful as a real test of what a plugin client's project likely looks like. Starting with a complete platform directory, and doing whatever the minimal changes are to keep it working, will likely reflect a common real-world scenario. On the flip side, the reason this doesn't use a complete 2.0.6 project, but instead is based on specific platform directories, is that we don't want to waste time manually maintaining, e.g., old Dart code that is irrelevant to the goal of the test. For now this only uses Android because that's where we've seen problems in practice, but we can alway add other legacy platform tests later if we find a need.
Fixes https://github.com/flutter/flutter/issues/125689
Because we treat analysis warnings as errors, there are common cases where non-breaking changes to part of a federated plugin (adding an enum value, deprecating a method, etc.) are CI-breaking for us. Currently we can't ignore those issues in the same PR where they are added, because doing so would violate the federated saftey check, adding extra complexity to those PRs.
This improves the change detection logic for the federated safety check to ignore comment-only changes in Dart code, which should allow us to add temporary `// ignore:`s in the PRs that create the need for them.
Fixes https://github.com/flutter/flutter/issues/122390
- Updates all macOS plugins to 10.14 as a minimum version, matching Flutter `stable`.
- Checks in the results of building all macOS examples with stable to bring them up to current with auto-migrations (and in some cases, with having ever been built, in the case of some examples with plugins where the CocoaPods changes were never committed).
All Runner.xcodeproj and Runner.xcworkspace changes are 100% tool-generated.
Also updates the repo tooling to know about a few more build-only example files that should not be flagged as potentially interesting for changelogs.
https://github.com/flutter/packages/pull/3973 caused an out-of-band
failure after publishing, because an example that uses `url_launcher`
had a too-old Kotlin version set. This is not something we consider
client-breaking because `flutter` prodives a very clear error message
with a straightforward and actionable fix step (update the app's Kotlin
version), so the fix for the breakage is just to update our own
examples.
Since increasingly we're likely to hit problems where modern version of
dependencies don't work with old version of Kotlin, this adds repo-wide
CI enforcement that examples are set to a minimum version (matching the
current `flutter/flutter` template; we can increase this over time as we
feel it's useful to do so).
- Adds a LUCI version of the Linux repo tools test, as a first test of a Linux repository test being migrated to LUCI.
- Fixes the Windows repo tools test to actually run a test, which it wasn't due to a mistaken duplicate yaml file, only one of which was correct (the one that wasn't being used).
Updates version-related checks for the 3.10 release:
- Updates the N-1 and N-2 tests to 3.3 and 3.7.
- Updates the minimum allowed SDK to declare support for to 3.3, matching our test matrix
- Updates all packages that were supporting <3.3 to 3.3 (and equivalent Dart versions for non-Flutter packages)
- Adds a Flutter->Dart mapping for 3.10 in the repo tooling.
Instead of running all test targets in the transitive dependency tree when running Android native unit tests via `gradlew`, specifically target the example app and the containing plugin. This avoids running tests from other packages (such as `flutter_plugin_android_lifecycle`).
Fixes https://github.com/flutter/flutter/issues/85057
When writing pub credentials, ensure that the target paths exists before
trying to write the file. In the past this would have worked because the
credentials were in the pub cache, and the pub cache would exist by the
time the repo tooling code was running. The new location, however, is a
configuration directory that is unlikely to exist before anything
involving `pub` credentials has run.
Should fix the latest `release` failure:
https://github.com/flutter/packages/actions/runs/4949005383/jobs/8854219784
As of Dart 3.0 (Flutter 3.10), the location that the tool was using for
the pub cache wasn't being read, breaking autopublish in CI. This
updates to the new location, and adds tests for it.
Should fix the fact that the `release` step hangs on every package
change now.
When making dependencies path-based using
`--target-dependencies-with-non-breaking-updates`, there was an edge case where a non-breaking change would cause breaking updates in packages that weren't on the latest version of the target. E.g., this happened when updating Pigeon from 9.0.0 to 9.0.1 and there were still packages using Pigeon 4.x-8.x.
Since the purpose of that flag is to find cases (particularly where we use it in CI) where publishing package B would break package A, we don't want to apply it in cases where the new version of B wouldn't be picked up by A anyway.
This adds filtering on a per-package level when in this mode, which validates that the on-disk package version is within the referencing package's constraint range before adding an override.
Fixes https://github.com/flutter/flutter/issues/121246
https://github.com/flutter/flutter/issues/125707
- Create pluginTools config for every example that shrunk material icons and had an android config
Likely some build caching but before/after If someone knows how to clean the cache or force a rebuild I will give more accurate after numbers.
Command
`time dart run ./script/tool/bin/flutter_plugin_tools.dart build-examples --apk`
Secondary validation from @stuartmorgan who discovered this is between a 10% and 25% speed increase.
Existing tests add confidence this is non-breaking. New tests not required because these are optional flags. Validation this does not change is low consequence. Test update to exclude these config files from changelog requirements.
The recent change to add `namespace` to all plugins broke builds for apps using AGP 4.1 or earlier. This conditionalizes setting the namespace based on whether the property exists at all, making it compatible with both AGP 8.0 and AGP <4.2.
Updates tooling to enforce this for plugin (but not example app) build.gradle files.
Fixes https://github.com/flutter/flutter/issues/125621
While current docs about `targetCompatibility` say that it defaults to `sourceCompatibility`, for older toolchains (AGP?) that is apparently not the case, and it's a build error to set `sourceCompatibility` without `targetCompatibility`.
This adds enforcement that it's set to `gradle-check`, and fixes all of the violations.
Fixes https://github.com/flutter/flutter/issues/125482
Moves the checks for Android warning configuration from `lint-android`, where it made sense to put them at the time, to the new `check-gradle`, which is a newer command specifically for validating that our Gradle files are following best practices.
Makes minor changes to the Pigeon platform test projects to make them conform to the checks, since they are now included in the run. The changes shouldn't actually change the behavior of the Pigeon tests.
Adds a `namespace` attribute to the Android build.gradle, for compatibility with Android Gradle Plugin 8.0, and adds tooling to enforce that it's there.
This is necessary for plugins now; for examples this isn't needed yet, but since it will be needed to eventually update the apps to AGP 8.0 anyway, it's easiest to just enforce it everywhere now.
Adds a repo tool command to validate that all plugins set an explicit Java compatibility version, instead of using whatever the local toolchain happens to be (which creates the potential for issues like https://github.com/flutter/flutter/issues/124839 where our CI passes but builds fail for some clients because our default is newer than theirs).
Currently that's all it checks, but we can add any other gradle best practices we want to enforce here in the future.
This also enables the new check in CI, and fixes all the violations it found.
Fixes https://github.com/flutter/flutter/issues/124839
For all Android plugins:
- Enable all warnings for `lint`
- Treat all warnings as errors for `lint`
This significantly increases the scope of issues that we'll catch in CI. To
allow enabling this without having to make tons of fixes first, so that
we get the incremental benefit immediately, this adds new baselines for
all plugins. We can incrementally clean those baselines up over time.
(In practice we haven't prioritized that, but it would be good to start
paying down that technical debt incrementally at some point.)
See https://github.com/flutter/flutter/issues/88011
Improves the `make-deps-path-based` command:
- When adding an override to a package, also adds it to that package's examples. This is needed for integration tests of app-facing packages of federated plugins when adding features to implementation packages, for instance.
- Switches from string-based rewrites to `yaml_edit` to make it more robust (necessary to do the above without major restructuring)
- Improves the auto-added comment since reviewers new to the repository are often confused by the overrides the first time they encounter them and think their inclusion in the PR is a mistake.
Fixes https://github.com/flutter/flutter/issues/111091
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
Since our existing `gradlew lint` check doesn't catch all warnings (notably, deprecation warnings, but also others like raw values), this:
- Configures our plugin example apps to enable `-Xlint:all -Werror` for the javac for the plugin project, so that we also get javac lint coverage in CI. This is done in the example app so that it won't affect plugin clients.
- Adds a check to `lint-android` that the example is configured this way, so that we don't forget to set it up when adding new plugins (or re-generating plugin examples from template).
Where it was trivial for me to just fix existing violations, I did so in this PR. For the rest that had violations, I commented out the enabling of the flags, with a TODO. Normally we would do this kind of thing with a `script/configs` file to opt packages out of a new check, but since this is part of an existing check rather than a whole new command, doing it that way would disable `gradlew lint` for those packages as well. Making a whole new command seemed more complex for the long term, so this seemed like the best short term option. We should try to remove as many of these opt-outs as possible ASAP.
Part of https://github.com/flutter/flutter/issues/91868
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).
Fixes an issue that showed up in the trial repo merge PR; if a pacakge
is new to the repository (i.e., has no git history in the parent
commit), it was being treated as a version bump, which caused failures
if NEXT was present. This adds a new state so that we can allow NEXT
during import.
The `firebase-test-lab` expectations were written for flutter/plugins,
where everything was supposed to have an integration test. This makes
non-plugin packages skip, not fail, if they don't have native
Android integration tests.
Fixes https://github.com/flutter/flutter/issues/120450
Follow-up to https://github.com/flutter/plugins/pull/7038 to try to make
it work on LUCI. Looking at the checkout steps of a LUCI run, it looks
like we do a full `fetch` of `origin`, but likely only have a `master`
branch locally. Rather than rely on a specific local branch name
existing, this allows for checking `origin` (and just in case, since
it's another common remote name, `upstream`).
Hopefully fixes https://github.com/flutter/flutter/issues/119330
* Standardize on .g.dart
* Remove unused exclusion patterns
* Mark pigeons/ as dev-only in the tooling
* Version bumps
* Add missed files
* More new import fixes
* [tool] Improve main-branch detection
Currently main-branch detection for `--packages-for-branch` looks at
branch names, but this no longer works on LUCI which now seems to be
checking out specific hashes rather than branches. This updates the
behavior so that it will treat any hash that is an ancestor of `main` as
being part of `main`, which should allow post-submit detection to work
under LUCI.
Fixes https://github.com/flutter/flutter/issues/119330
* Fix throw
* Fix typos
* Update comment
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.
When determining whether or not to fail with `--fail-on-change`, only
look at .md files. In some cases, running the necessary commands (e.g.,
`flutter pub get`) may change unrelated files, causing fales positive
failures. Only changed documentation files should be flagged.
Also log the specific files that were detected as changed, to aid in
debugging any future false positives.
Fixes https://github.com/flutter/flutter/issues/111592
Fixes https://github.com/flutter/flutter/issues/111590
