Imports https://github.com/dnfield/vector_graphics into this repository,
with history, and updates it to follow repository conventions:
- Adds missing licence headers.
- Removes analysis options and fixes resulting warnings.
- Updates min SDKs.
- Autoformats.
- Updates pubspecs to follow repo standard, including updating the
metadata
to point to the Flutter repositories.
- Allows `xml` as a pinned dependency, and relaxes the pinning
requirement
in the repo tools to allow an explicit, inclusive-endpoint range.
- Skips some unit tests on unsupported platforms.
- Adds repo metadata.
- Bumps versions and slightly relax version constraints to allow the new
versions.
Currently the autoformatter check is run per-package, so doesn't include script/tool. This adds a new CI step to check the formatting of the repo tooling, just as we have for running its unit tests.
Fixes `--current-package` so that when run on a package in third_party/packages/ in works as expected, rather than failing with an error message saying that it must be run from inside a package.
`made-deps-path-based` would sometimes create invalid relative paths when `third_party/packages` was involved because it was using the sibling directory of `packages` as the base. This updates the logic to always make the paths relative to the repository root; this is often a longer relative path than necessary, but that's harmless, and always using the repo root makes it easier to reason about.
Also fixes the fact that paths that were already path based (which is always the case for `some_package/example`'s dependency on `some_package`) were being overridden, causing CI to do some unnecessary duplicate analysis work.
Minor cleanup of the script to create the build-all app, mostly for Android:
- Don't override the minSdk to 21, since the Flutter-provided value is now 21 already.
- Don't enable multidex, since that isn't necessary for minSdk 20+.
- Remove camera_android_camerax from the direct dependency list, not camera_android, now that the endorsement has switched. This will return us to the previous, intended behavior of testing that both versions build together.
- If for some reason the Dart SDK isn't detected, use 3.0.0+ instead of 2.12.0+.
- 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.
Now that `stable` requires AGP 7.0, which in turn requires Java 11+, we should be able to set our compatibility version to 11 (setting the min Flutter SDK version to current stable).
Also removes the gradle conditionals for setting namespace (and the repo tool checks that it is present), as that was only needed for AGP 4.1 compatibility.
Part of https://github.com/flutter/flutter/issues/156111
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.
macOS privacy manifest enforcement is rolling out soon, so this brings all macOS plugins into alignment with our iOS policy of always having a manifest, including updating the repo tooling to enforce that.
Very few plugins are affected because most share the implementation package with iOS, and we didn't do any target platform switching when adding the manifests for iOS, automatically covering macOS as well.
Fixes https://github.com/flutter/flutter/issues/155564
Upgrades all AGP versions less than 8 to latest. The primary motivation is to prepare for https://github.com/flutter/flutter/issues/136879#issuecomment-2292073921, which requires that plugins use a non-7.3 version. We believe it only affects version 7.3 - I'm going to test this, but am not sure the exact range yet and updating is independently valuable, so I just updated all pre 8 versions (it doesn't affect 8+).
Also:
- Upgrades Gradle versions as required
- Marks the use of `Camera2Interop` with `@OptIn`, as it is required by the newer AGP version.
- Changes the Camerax example java directory path to align with the package xml attribute/AGP namespace attribute.
- Sets `android.buildFeatures.buildConfig` to true for compatibility with AGP 8.0+ in some places.
- Sets `exported=true` in a manifest, requires for AGP bump.
- Updates espresso in some examples, required by the AGP bump (0.2.0 isn't compatible with AGP 8.0+).
Also related to https://github.com/flutter/flutter/issues/146660
This PR:
* Modifies the `version_check_command` test so it checks the leading markdown of the first line of a CHANGELOG file, to ensure it's `'##'`.
* Fixes the CHANGELOG in two packages that were allowed by the tool before this fix:
* google_maps_flutter_web
* interactive_media_ads
## Issues
Fixes https://github.com/flutter/flutter/issues/152638
When running publish-check, any pre-publish hook must be run before the `publish --dry-run` step as the latter succeeding may depend on the former.
Part of https://github.com/flutter/flutter/issues/150210
I was unsure if we wanted to add a new platform option for this or add a `--wasm` flag to the command. Adding a `--wasm` flag seems more complicated since we would probably want to add extra handling around proper use of the flag, whereas adding a `web-wasm` platform should require no additional checks.
This is in preparation for https://github.com/flutter/flutter/issues/151664
Adds the ability for a package to specify a script that should be run before publishing. To minimize the chance of such a script breaking things only in the post-submit `release` step, if the script is present it will also be run during `publish-check`.
These should be used with caution since they can cause the published artifacts to be different from that is checked in, but in the intended use case of extension builds this risk is far preferable to the risks associated with checking in binaries that were built on local, ad-hoc basis. (Longer term, we may need an alternate solution however, as generating artifacts in CI can have its own supply chain validation issues.)
Also does some minor refactoring to custom test script code to make it follow the same pattern as this new code.
Fixes https://github.com/flutter/flutter/issues/150210
Configures the flutter/packages CI to run web tests using the `canvaskit` renderer, which is the new default for web apps.
It also does some minor changes:
* Skips tests on the web for `package:palette_generator` (cleanup issue created below)
* Makes the `palette_generator` example run on the web. This was used to manually verify that the package still works as expected with canvaskit.
* Tweaks the README of the `pointer_interceptor` example apps, so they match what's happening in there.
## Issues
* Fixes https://github.com/flutter/flutter/issues/143543
Co-authored-by: David Iglesias <ditman@gmail.com>
The logic for handling Dart unit test `test_on` directives was incorrect, causing it to skip packages that required vm testing, even when run in vm mode. This PR:
- Adds the missing tests for false negatives.
- Reworks the logic to explicitly fail for anything that isn't one of the exact patterns we are expecting, to make it much harder to re-introduce a bug like this in the future.
Currently if a PR follows the recommended combo PR process for a federated plugin, the main PR will have CI errors that say the PR isn't allowed to do what it is doing, which is confusing, especially to new contributors or reviewers.
This updates the tooling to detect the temporary overrides created by the tooling, and uses that to trigger a different error message that explains that the error is expected, and exists only to prevent accidental landing.
Fixes https://github.com/flutter/flutter/issues/129303
macOS 14 added new requirements that un-codesigned sandbox apps must be granted access when changed. Waiting for this UI caused macOS tests to fail on macOS 14. Additionally, adding codesigning is not sufficient, since it must still be approved before codesigning is enough to pass the check. As a workaround, this PR disables sandboxing for macOS tests in CI.
https://developer.apple.com/documentation/updates/security#June-2023)
> App Sandbox now associates your macOS app with its sandbox container using its code signature. The operating system asks the person using your app to grant permission if it tries to access a sandbox container associated with a different app. For more information, see [Accessing files from the macOS App Sandbox](https://developer.apple.com/documentation/security/app_sandbox/accessing_files_from_the_macos_app_sandbox).
And that link explains why this is happening on a macOS 14 update:
> In macOS 14 and later, the operating system uses your appâs code signature to associate it with its sandbox container. If your app tries to access the sandbox container owned by another app, the system asks the person using your app whether to grant access. If the person denies access and your app is already running, then it canât read or write the files in the other appâs sandbox container. If the person denies access while your app is launching and trying to enter the other appâs sandbox container, your app fails to launch.
>
> The operating system also tracks the association between an appâs code signing identity and its sandbox container for helper tools, including launch agents. If a person denies permission for a launch agent to enter its sandbox container and the app fails to start, launchd starts the launch agent again and the operating system re-requests access.
Fixes packages part of https://github.com/flutter/flutter/issues/149264.
Verified tests pass:
https://ci.chromium.org/ui/p/flutter/builders/staging.shadow/Mac_arm64%20macos_platform_tests%20master%20-%20packages/6/overview
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.
Converts native unit tests from Objective-C to Swift, as a first step toward an eventual plugin conversion. Since OCMock usage was removed in a previous PR, the tests are converted essentially directly (the rewrites were largely mechanical syntax replacement), without any changes needed to production code.
There are a few places where interacting with the Pigeon-generated Obj-C is somewhat awkward because the NSError signature isn't auto-converting to `throw` in cases where we use `NSNumber` wrapping, but all that will get cleaned up when we switch the plugin over to Swift Pigeon generation and have idiomatic Swift APIs that the tests will be calling instead.
Fixes a couple of false positives in the repo tooling surfaced by this PR:
- `darwin/Tests/` wasn't recognized as a test directory.
- Swift tests weren't recognized as exempt from requiring Swift entries in the podspec.
Part of https://github.com/flutter/flutter/issues/119104
Usually when an iOS plugin uses Swift files, it requires a workaround in the podspec to add Swift to the search paths. Part of the `podspec-check` command is validating this workaround is found. However, when the only Swift file is the `Package.swift` (Swift Package Manager manifest), skip this validation since having this file does not indicate the plugin uses Swift files.
Fixes https://github.com/flutter/flutter/issues/147548.
- 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
Reverts: flutter/packages#6416
Initiated by: ditman
Reason for reverting: Failures happen (later) in other plugins (more updates in the related issue)
https://github.com/flutter/flutter/issues/145866
Original PR Author: ditman
Reviewed By: {jmagman}
This change reverts the following previous change:
Adds `--allow-warnings` to podspec_check_command.dart so stuff can keep rolling.
**To be removed soon!**
Adds the flowing to the tool:
- A new `--exact-match-only` flag to be used with `--packages` to prevent group matching (i.e., a selection like `--packages=path_provider --exact-match-only` would only run on `packages/path_provider/path_provider`, not `packages/path_provider/*`).
- Two new `publish` command flags:
- `--tag-for-auto-publish`, to do all the steps that `publish` currently does except for the real `pub publish`, so it would dry-run the publish and then create and push the tag if successful.
- `--already-tagged`, to skip the step of adding and pushing a tag, and replace it with a check that `HEAD` already has the expected tag.
This set of additions supports a workflow where the current `release` step is changed to use `--tag-for-auto-publish`, and then the separate auto-publish system would publish each package with `... publish --already-tagged --packages=<some package> --exact-match-only`.
See https://github.com/flutter/packages/pull/5005#discussion_r1344542422 for previous discussion/context.
Part of https://github.com/flutter/flutter/issues/126827
