[web] Update package:web to ">=0.5.1 <2.0.0"

[ditman]

This PR updates packages that depend on package:web to web: ">=0.5.1 <2.0.0".

Issues

• Fixes: Upgrade all packages to package:web version 1.0.0 flutter#151981

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene 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/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to 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, or this PR is exempt from CHANGELOG changes.
• 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.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[ditman]

(First push to see how CI likes this, expecting a bunch of errors!)

[ditman]

Because google_identity_services_web >=0.3.1+1 depends on web ^0.5.1 and google_identity_services_web >=0.3.1 <0.3.1+1 depends on web ^0.5.0, google_identity_services_web >=0.3.1 requires web ^0.5.0.
So, because google_sign_in_web depends on both google_identity_services_web ^0.3.1 and web ^1.0.0, version solving failed.

Because google_maps_flutter_web depends on google_maps ^7.1.0 which depends on web ^0.5.0, web ^0.5.0 is required.
So, because google_maps_flutter_web depends on web ^1.0.0, version solving failed.

• google_identity_services_web needs to be published first.
  • [gis_web] Allow package:web 1.0.0 #7203
• We also need an update of google_maps to web: ^1.0.0 (maybe in the 8 branch?)
  • Allow package web: ^1.0.0 a14n/dart-google-maps#135, and then
    • [google_maps_flutter_web] Migrate to google_maps: 8.0.0 #7077

[yjbanov]

[Rexios80]

@ditman There is some cleanup to do that won't show up as build errors since a lot of the import statements are like this:

import 'package:web/web.dart' as web;

which will hide duplicate type errors

package:web 1.0.0 added a lot of types, functions, fields, etc that currently exist in custom extensions. For example in video_player_web:

import 'package:web/web.dart' as web;

/// Adds a "disablePictureInPicture" setter to [web.HTMLVideoElement]s.
extension NonStandardSettersOnVideoElement on web.HTMLVideoElement {
  // TODO(srujzs): This will be added in `package:web` 0.6.0. Remove this helper
  // once it's available.
  external set disablePictureInPicture(bool disabled);
}

/// Adds a "disableRemotePlayback" and "controlsList" setters to [web.HTMLMediaElement]s.
extension NonStandardSettersOnMediaElement on web.HTMLMediaElement {
  // TODO(srujzs): This will be added in `package:web` 0.6.0. Remove this helper
  // once it's available.
  external set disableRemotePlayback(bool disabled);
  external set controlsList(String? controlsList);
}

[stuartmorgan-g]

For any packages without any code changes (which is currently all of them, but I'm not sure how preliminary that is), consider expanding the range to include 1.x instead of requiring 1.x. According to pub there are about 150 packages depending on web, including a bunch of popular ones. The more packages that do a gradual transition allowing 0.5 or 1.x for a little while instead of going straight to requiring 1.x, the fewer people will have resolver errors that prevent them from using the latest versions of all of their packages as the transition works its way through the ecosystem.

Not a requirement by any means, but something to consider.

[ditman]

package:web 1.0.0 added a lot of types, functions, fields, etc that currently exist in custom extensions. For example in video_player_web:

@Rexios80 you're right, I'll eventually get to those as we fix the more core dependencies. There's only a few "package_web_tweaks" in the different packages which should be "easy to remove".

will hide duplicate type errors

@Rexios80 we have fairly strict warnings-as-errors in the build; I think those errors will eventually show up once the "all_packages" app is able to resolve to web:^1.0.0. Or do you mean those will fail at run-time or some time after publishing?

For any packages without any code changes (which is currently all of them, but I'm not sure how preliminary that is), consider expanding the range to include 1.x instead of requiring 1.x.

Good call @stuartmorgan, I'll try to expand the untouched packages to a range, as long as the code is compatible.

[Rexios80]

we have fairly strict warnings-as-errors in the build; I think those errors will eventually show up once the "all_packages" app is able to resolve to web:^1.0.0. Or do you mean those will fail at run-time or some time after publishing?

I'm not sure they will show up as warnings/errors since technically nothing will be wrong. The extensions will just shadow the real types (if the web import is named) and fields (always). They should still build fine, there will just be superfluous code.

[ditman]

I'm not sure they will show up as warnings/errors since technically nothing will be wrong. The extensions will just shadow the real types (if the web import is named) and fields (always). They should still build fine, there will just be superfluous code.

@Rexios80 Ah yes, I think this is fine (for a while). IMO it's very nice that we can write this type of "bridge" code across major versions for a change! 😭

We can (and should) remove the package_web_tweaks files once we bump the dependency to ^1.0.0 only (and not the range). For example, we could use this PR to clean up the small tweaks that google_maps_flutter_web has to package:web, if we want to make it web:1.0.0 only.

As @stuartmorgan said, the packages that don't require actual code changes to go to web:^1.0.0, should support the >=0.5.1 <2.0.0 range until they must be moved to ^1.0.0 (because of us needing some feature from the package). It seems that the tweaks needed to support the web range are pretty small anyways! 🤞

[Rexios80]

As @stuartmorgan said, the packages that don't require actual code changes to go to web:^1.0.0, should support the >=0.5.1 <2.0.0 range until they must be moved to ^1.0.0 (because of us needing some feature from the package). It seems that the tweaks needed to support the web range are pretty small anyways! 🤞

In the past I would be opposed to maintaining a version range on a dependency since it's really easy to accidentally break backwards compatibility. However pana now checks packages after running pub downgrade so this is no longer an issue!

[stuartmorgan-g]

In the past I would be opposed to maintaining a version range on a dependency since it's really easy to accidentally break backwards compatibility. However pana now checks packages after running pub downgrade so this is no longer an issue!

We've been doing that in our CI, as part of presubmit checks, for two years. The pana check was actually added because I recommended it based on our setup.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[ditman]

(This should trigger all tests?)

[Rexios80]

Just some small things I noticed. Otherwise LGTM!

[Rexios80]

Since there is a code change in this package, should this be 2.1.0?

[ditman]

Nah, the code changes are so minimal that I think a patch version should be enough.

[Rexios80]

@ditman Should we ask for a test exemption on Discord?

[ditman]

@ditman Should we ask for a test exemption on Discord?

@Rexios80 it's almost 8PM PT, so it's probably a little bit late (or too early) for Discord.

@stuartmorgan has test exemption powers and can also answer your question about the web_benchmarks version; I'm sure this'll be ready to autosubmit early tomorrow!

[stuartmorgan-g]

test-exempt: code refactor with no semantic change

[kevmoo]

auto-submit?

[Rexios80]

@kevmoo There are some small tweaks left

[ditman]

OK, I've addressed all of the comments. It seems that if CI is happy, we're all happy, so adding autosubmit to this PR (will keep an eye on flakes just in case)

[ditman]

This is now published, thanks!

Run overview:
  packages/packages/cross_file - published
  packages/packages/file_selector/file_selector_web - published
  packages/packages/google_identity_services_web - published
  packages/packages/google_maps_flutter/google_maps_flutter_web - published
  packages/packages/google_sign_in/google_sign_in_web - published
  packages/packages/image_picker/image_picker_for_web - published
  packages/packages/pointer_interceptor/pointer_interceptor_web - published
  packages/packages/shared_preferences/shared_preferences_web - published
  packages/packages/url_launcher/url_launcher_web - published
  packages/packages/video_player/video_player_web - published
  packages/packages/web_benchmarks - published
  packages/packages/webview_flutter/webview_flutter_web - published