Several dev dependencies, most notably mockito, were only allow as exactly pinned versions, in order to avoid out-of-band breakage due to deprecations in minor version updates. Now that the policy for Flutter repos has changed to not include deprecation warnings in analysis, this is no longer an issue, so we can relax these dependencies to follow the more normal pattern of using ranges.
Updates to the latest version of `mockito`.
This PR is entirely tool-generated, using the `update-dependency --pub-package=mockito` repo tooling command.
The test mixin is currently declared as a `class`, which causes problems for projects with a minimum Dart version of 3.0. This switches it to `mixin class`; ideally it would just be a `mixin`, but in theory that could break something, so since this is such a core package in the ecosystem we want to be as conservative as possible. (While the breaking change would only in theory happen to test code, it's possible that someone ignored the `visibleForTesting`, and we have an easy way to avoid the possibility entirely.)
Fixes https://github.com/flutter/flutter/issues/123241
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).
- Updates the N-1 and N-2 analysis bot configs to 3.7 and 3.10
- Updates the minimum allowed SDK to 3.7, since that's now the earliest we have any testing for.
- Updates all packages to Flutter 3.7/Dart 2.19 as a minimum.
- In packages where we hadn't released since the last minimum version bump, I removed the previous line from the `#NEXT` section to make it less confusing when we do release.
Per https://github.com/flutter/flutter/wiki/Contributing-to-Plugins-and-Packages#version this does not update any package versions.
Updates the README to use code excerpts from the unit test file, adjusting the existing test code slightly to make it suitable for use in the example.
Also fleshes out the example a bit more, to make it look more like a real class.
Finally, adds a note about `base`, linking to the ongoing discussion, since we don't have a decision yet, but people may well wonder why this class exists given `base`.
Part of https://github.com/flutter/flutter/issues/102679
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.
This change replaces `PlatformInterface._instanceToken` (an instance
field that points from a `PlatformInterface` to its corresponding
token) with an expando that maps from `PlatformInterface` to `Object`.
There is no change to the public API, and no change to the behavior of
users' production code.
This change ensures that if a customer tries to implement
`PlatformInterface` using `implements` rather than `extends`, the code
in `PlatformInterface._verify` won't try to access the private
`_instanceToken` field in `PlatformInterface`. This is important
because an upcoming change to the dart language is going to cause such
accesses to throw exceptions rather than deferring to `noSuchMethod`
(see https://github.com/dart-lang/language/issues/2020 for details).
Fixes https://github.com/flutter/flutter/issues/109339.
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 new `verify` method worked with `Mock` (since `_instanceToken`
returns a stub function in that case), but not `Fake` or a manual fake
since it was unconditionally accessing `_instanceToken`. This fixes that
new check to be gated behind the `MockPlatformInterfaceMixin` test, and
adds a unit test that covers `Fake` so this can't regress in the future.
Fixes post-publish breakage in the tree.
- Introduce `verify`, a more future-proof name. It throws `AssertionError` if `const Object()` used as the instance's token.
- Soft-deprecate `verifyToken` with a comment. It will actually deprecated in a future release, to avoid breaking tests with this minor change.
- Update documentation for `PlatformInterface` to show new usage of `verify` and other cosmetic fixes.
- Add a test for the new assertion.
Fixes https://github.com/flutter/flutter/issues/96178.
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.
Remove a few of the trivial-to-fix legacy analysis option files that were bulk added in the transition to matching flutter/flutter's analysis options.
Part of flutter/flutter#76229
- Standardize on mockito 5.0 now that the conflicts with SDK packages is
resolved on stable.
- Removes overrides that were only needed for Flutter 2.0
- Update a -nullsafe inter-package dependency
- Update some older federated examples that used dependency_overrides to
depend on its encloding package by path to the now-standard option of
listing that path-based dependency directly.
Regularizes the pubspec.yaml files of the plugins:
- Changes from `homepage` to `repository` to improve the linking on pub.dev.
- Adds an `issue_tracker` link that links directly to a search on that plugin's label, to improve the linking on pub.dev.
- Standardizes the section order as `environment`, `flutter`, `dependencies`, `dev_dependencies`. This matches the current template, except that `flutter` is higher as it's critical information in a plugin (which should potentially be revisited in the template).
- Sorts dependencies within each section.
- Updates the Flutter SDK versions to 2.0.0; in practice this is already the case due to the Dart SDK version requirement, so this just makes it less confusing.
- Standardizes the location of `version` in the initial block.
Changes that were considered out of scope:
- Actually cleaning up dependencies (e.g., removing meta where it's no longer needed). The goal was to make this PR as mechanical as possible, and to not change any actual behavior).
- The example/ pubspecs (just to limit the scope of the PR; we should eventually clean those up too).
- Plugins that have Plus Plugin equivalents, per repo policy, as this is a non-critical change.
This does not update versions; these changes can be picked up the next time the plugins happen to be published.
This also doesn't add automated enforcement. We should consider that in the future though; filed as https://github.com/flutter/flutter/issues/82913
Standardizes all first-party copyrights on a single year, as is done in flutter/flutter and flutter/engine. All code now uses 2013, which is the earliest year that was in any existing copyright notice.
The script checks now enforce the exact format of first-party licenses and copyrights.
Fixesflutter/flutter#78448
In all copyright messages (and in the Xcode project organization name) standardize on "The Flutter Authors", adding "The Chromium Authors" to the Flutter AUTHORS list. This reduces inconsistency in the copyright lines in this repository, moving closer to a single consistent copyright+license (as in flutter/engine and flutter/flutter)
Updates the validation script to no longer accept "The Chromium Authors" or "the Chromium project authors" in first-party code.
This ensures that the AUTHORS list is distributed with the plugins whose copyright blocks refer to the project authors, for ease of reference. This is currently a copy of the top-level authors list, but over time they are expected to diverge as people contribute to specific plugins.
This does not bump plugin versions or CHANGLELOGs, since it has no effect on the plugin itself; it will be picked up over time as we ship new versions of plugins.
Part of https://github.com/flutter/flutter/issues/78448
Renames the old analysis_options.yaml to analysis_options_legacy.yaml,
replacing it with a slightly modified copy of flutter/flutter's analysis
options.
Each plugins has a temporary local analysis_options.yaml that points to
the legacy version. This allows for inceremental conversion on a
per-plugin basis, which should make the problem more tractable.
Since this hasn't yet been enabled for any packages, it's likely that as
it is we'll find a few local modification we need to make to the root
analysis_options (e.g., things that conflict with 'dart format').
Part of https://github.com/flutter/flutter/issues/76229
This cleans up a number of unnecessary differences in the LICENSE files:
- Removes C++ comments ("// ") from the beginnings of all the lines in license files that had them.
- Standardizes on having a blank line after the copyright line.
- Standardizes on having the final newline in the file.
- Standardizes on the indentation of the bulleted conditions.
- Standardizes on the locations of line breaks (re-wrapping the text)
This makes the license bodies--not including the copyright line--in almost all files the same, and matches the exact formatting already used in flutter/flutter and flutter/engine.
The only remaining non-copyright-line differences should now be:
- packages/image_picker/image_picker/LICENSE has an extra license
- packages/google_sign_in/extension_google_sign_in_as_googleapis_auth/LICENSE use "Google LLC" rather than "Google Inc." in the third condition.
Adds a package with a common base class for platform interface.
The PlatformInterface class provides common functionality for enforcing that platform implementations extend the platform interface with extends rather than implement it with implements.
This is based on the existing code from the url_laucher_platform_interface, and the improvements proposed in #2326
