Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

[url_launcher] Support new desktop implementation versions #4779

Conversation

stuartmorgan-g
Copy link
Contributor

Fixes default_package typos for the Linux, macOS, and Windows
implementations, allowing Dart registration to work correctly. Updates
the constraints to allow the new major versions of those packages, which
have major version bumps only to prevent older versions of
url_launcher from picking them up, since their Dart registration won't
work prior to this fix.

Also adds repository tooling to prevent this kind of typo from slipping
in again.

Long-term fix for flutter/flutter#98097

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
  • I signed the CLA.
  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I listed at least one issue that this PR fixes in the description above.
  • I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
  • I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is test-exempt.
  • All existing and new tests are passing.

Fixes default_package typos for the Linux, macOS, and Windows
implementations, allowing Dart registration to work correctly. Updates
the constraints to allow the new major versions of those packages, which
have major version bumps only to prevent older versions of
`url_launcher` from picking them up, since their Dart registration won't
work prior to this fix.

Long-term fix for flutter/flutter#98097
@stuartmorgan-g
Copy link
Contributor Author

stuartmorgan-g commented Feb 9, 2022

Note: I'm posting this for review now, but before landing we should wait until the url_launcher_* packages have been published and then re-run the Linux, macOS, and Windows tests so that they are being tested against the 3.0 versions. This initial run will be against the 2.0.x versions since at time of posting the 3.x's haven't been published.

@stuartmorgan-g
Copy link
Contributor Author

Re-run passed

Copy link
Member

@ditman ditman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (with a small comment about the approach to verify the default_package name through the pubspec deps, instead of the package name being a prefix of the default_package name?)

output,
containsAllInOrder(<Matcher>[
contains(
'"plugin_b_android" is not an expected implementation name for "plugin_a"'),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great!

Comment on lines +278 to +281
if (!defaultPackage.startsWith('${packageName}_')) {
return '"$defaultPackage" is not an expected implementation name '
'for "$packageName"';
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this, why not check that defaultPackage is contained as a dependency of the plugin?

That way we could still endorse packages that have a name that doesn't start with packageName (because it might be taken, or because somebody else started the plugin before this rule went into effect?), and have some validation that we're using the correct value for the name of the dependency?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of this, why not check that defaultPackage is contained as a dependency of the plugin?

That's the very next block of code :)

That way we could still endorse packages that have a name that doesn't start with packageName (because it might be taken, or because somebody else started the plugin before this rule went into effect?)

The reason I did this in addition is that I think it's useful to enforce prefix naming; even if the name we might normally use is taken, I think we should avoid the collision via suffix changes rather than breaking our core naming pattern.

Copy link
Member

@ditman ditman Feb 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the very next block of code :)

🤦 Gonna grab some coffee, my attention span is shrinking dangerously!

even if the name we might normally use is taken, I think we should avoid the collision via suffix changes rather than breaking our core naming pattern.

Yeah, we've had to do it with some "_for_web" packages. I was thinking more on the case that somebody else has a plugin for some platform and they've already published it as: "contoso_better_url_launcher_for_windows" or similar, and then we want to make that the endorsed implementation. That'll probably never happen, though :P

@stuartmorgan-g stuartmorgan-g added the waiting for tree to go green (Use "autosubmit") This PR is approved and tested, but waiting for the tree to be green to land. label Feb 10, 2022
@fluttergithubbot fluttergithubbot merged commit 04d5fa9 into flutter:main Feb 10, 2022
@stuartmorgan-g stuartmorgan-g deleted the url-launcher-registration-typo-fix-part-ii branch April 19, 2022 17:33
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
p: url_launcher waiting for tree to go green (Use "autosubmit") This PR is approved and tested, but waiting for the tree to be green to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants