Deprecate --packages flag and add --package #370
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
natebosch
reviewed
Mar 14, 2022
Michael thinks we should delete the flag. We can discuss it more here: #369 |
liamappelbe
changed the title
kevmoo
reviewed
Mar 22, 2022
|
Friendly ping @natebosch . I think this is ready to go. I've switched it from deleting the old flag/api to just deprecating it. |
natebosch
approved these changes
Mar 29, 2022
8 tasks
cbracken
added a commit
to cbracken/flutter
that referenced
this pull request
May 14, 2022
This rolls depdendencies to latest using flutter update-packages --force-upgrade This change includes three code changes: * Removes charcode from the dependencies allowlist since it no longer appears in the transitive closure of dependencies of the flutter, flutter_test, flutter_driver, flutter_localizations, and integration_test packages. * Uses Resolver.create instead of the deprecated Resolver constructor. The default Resolver constructor has been deprecated in favour of the static Resolver.create() factory function, which unfortunately happens to be async. Propagated the async-ness up the chain. * Eliminates the use of the deprecated packagesPath parameter to HitMap.parseJson. This parameter was deprecated and replaced with packagePath in dart-lang/coverage#370 which was part of the overall deprecation of the .packages file in Dart itself dart-lang/sdk#48272. The overall goal being that end-user code shouldn't need to know about implementation details such as whether dependency information is stored in a .packages file or a package_info.json file, but rather use the package_config package to obtain the package metadata and perform other functions such as resolving its dependencies to filesystem paths. packagesPath was replaced by packagePath, which takes the path to the package directory itself. Internally, package:coverage then uses package_config to do the rest of the package/script URI resolution to filesystem paths. This is a pre-update prior to updating flutter_template_images in flutter#103739 Issue: flutter#103371 Issue: flutter#103775
|
@liamappelbe @natebosch looks like this was soft-breaking to Flutter (though our lint rules cause this to be hard-breaking). I've got a patch that fixes it up here: Unfortunately, applying that patch would break google3, because package:coverage appears to not have rolled to google3 yet, as a result, we're blocked on all flutter depdendency upgrades at the moment. Is there a plan to roll this in soon? |
|
I've temporarily marked these uses as |
cbracken
added a commit
to flutter/flutter
that referenced
this pull request
May 14, 2022
Roll dependendencies This rolls depdendencies to latest using flutter update-packages --force-upgrade This change includes three code changes: * Removes charcode from the dependencies allowlist since it no longer appears in the transitive closure of dependencies of the flutter, flutter_test, flutter_driver, flutter_localizations, and integration_test packages. * Uses Resolver.create instead of the deprecated Resolver constructor. The default Resolver constructor has been deprecated in favour of the static Resolver.create() factory function, which unfortunately happens to be async. Propagated the async-ness up the chain. This change was partially reverted and the deprecation ignored in this patch until package:coverage can be rolled internally at Google. * Eliminates the use of the deprecated packagesPath parameter to HitMap.parseJson. This parameter was deprecated and replaced with packagePath in dart-lang/coverage#370 which was part of the overall deprecation of the .packages file in Dart itself dart-lang/sdk#48272. The overall goal being that end-user code shouldn't need to know about implementation details such as whether dependency information is stored in a .packages file or a package_info.json file, but rather use the package_config package to obtain the package metadata and perform other functions such as resolving its dependencies to filesystem paths. packagesPath was replaced by packagePath, which takes the path to the package directory itself. Internally, package:coverage then uses package_config to do the rest of the package/script URI resolution to filesystem paths. This change was partially reverted and the deprecation ignored in this patch until package:coverage can be rolled internally at Google. This is a pre-update prior to updating flutter_template_images in #103739 Issue: #103371 Issue: #103775 Issue: #103830 When re-applying the partially-reverted changes to code coverage, we'll need to patch host_entrypoint.dart internally to await the Future that we'll be returning rather than a non-async value.
8 tasks
cbracken
added a commit
to flutter/flutter
that referenced
this pull request
May 31, 2022
In #103771, we rolled dependencies in Flutter, which triggered an update of package:coverage to v1.3.1. The new version includes dart-lang/coverage#370 in which two deprecations landed: * The `Resolver` default constructor was deprecated and replaced with the `Resolver.create` static factory method, which unfortunately happens to be async. * The `packagesPath` parameter to `HitMap.parseJson`, which takes the path to the `.packages` file of the package for which coverage is to be collected, was deprecated. This parameter was replaced with `packagePath` in dart-lang/coverage#370 which was part of the overall deprecation of the .packages file in Dart itself dart-lang/sdk#48272. The overall goal being that end-user code shouldn't need to know about implementation details such as whether dependency information is stored in a .packages file or a package_info.json file, but rather use the package_config package to obtain the package metadata and perform other functions such as resolving its dependencies to filesystem paths. packagesPath was replaced by packagePath, which takes the path to the package directory itself. Internally, package:coverage then uses package_config to do the rest of the package/script URI resolution to filesystem paths. This migrates off the deprecated `packagesPath` parameter to the replacement `packagePath` paramter. Issue: #103830
camsim99
pushed a commit
to camsim99/flutter
that referenced
this pull request
Aug 10, 2022
In flutter#103771, we rolled dependencies in Flutter, which triggered an update of package:coverage to v1.3.1. The new version includes dart-lang/coverage#370 in which two deprecations landed: * The `Resolver` default constructor was deprecated and replaced with the `Resolver.create` static factory method, which unfortunately happens to be async. * The `packagesPath` parameter to `HitMap.parseJson`, which takes the path to the `.packages` file of the package for which coverage is to be collected, was deprecated. This parameter was replaced with `packagePath` in dart-lang/coverage#370 which was part of the overall deprecation of the .packages file in Dart itself dart-lang/sdk#48272. The overall goal being that end-user code shouldn't need to know about implementation details such as whether dependency information is stored in a .packages file or a package_info.json file, but rather use the package_config package to obtain the package metadata and perform other functions such as resolving its dependencies to filesystem paths. packagesPath was replaced by packagePath, which takes the path to the package directory itself. Internally, package:coverage then uses package_config to do the rest of the package/script URI resolution to filesystem paths. This migrates off the deprecated `packagesPath` parameter to the replacement `packagePath` paramter. Issue: flutter#103830
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add a
--packageflag to format_coverage, which takes the package's root directory, instead of the .package file. This flag defaults to the current working directory, so in the common case the user won't have to pass it at all. Deprecate the--packagesflag.Also, deprecate the packagesPath parameter and add packagePath instead, in
HitMap.parseJson,HitMap.parseFiles,createHitmap, andparseCoverage.Fixes #369