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).
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
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
This removes all of the deprecated plugins from the tree, as well as all references to them.
They were being left in the tree only in case they needed critical fixes before the end of this year, when they will become completely unsupported and be officially discontinued on pub.dev. The end of the year is now close enough that such a release is extremely unlikely, and they are causing some maintenance burden (e.g., the tree is currently closed on an out-of-band failure in android_alarm_manager). In the event that we do have to push an emergency fix in the next several weeks, we can either temporarily restore the plugin from git history, or use a branch.
Minor related cleanup:
- Scanning the repository for remaining references turned up that `image_picker_for_web` and `video_player_for_web` had copypasta'd the package name of its example application from one of the deprecated plugins, so this fixes those names.
- Fixes `federation-safety-check` handling of top-level files in unfederated plugins that accidentally tripped federated plugin heuristics.
- Fixes `federation-safety-check` handling of deleted plugins, as it was crashing, and tests that.
- Fixes `make-deps-path-based` handling of deleted plugins, as it was crashing, and tests that.
Adds a new command that adds `dependency_overrides` to any packages in the repository that depend on a list of target packages, including an option to target packages that will publish a non-breaking change in a given diff.
Adds a new CI step that uses the above in conjunction with a new `--run-on-dirty-packages` to adjust the dependencies of anything in the repository that uses a to-be-published package and then re-run analysis on just those packages. This will allow us to catch in presubmit any changes that are not breaking from a semver standpoint, but will break us due to our strict analysis in CI.
Fixes https://github.com/flutter/flutter/issues/89862