Update the use of 'package:shelf_web_socket's webSocketHandler method

[devoncarew]

• add a 2nd argument to the closure passed into package:shelf_web_socket's webSocketHandler method
• widen the dep on package:shelf_web_socket

This will allow us to add more type info to the closure that webSocketHandler expects; it's currently an untyped Function. See also dart-lang/shelf#457 and dart-lang/shelf#463.

This forward declares compatibility with 3.0 of package:shelf_web_socket; I think this is necessary - as dart test uses both package:test and package:shelf_web_socket - but happy to hear otherwise.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[github-actions]

PR Health

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

[jakemac53]

We should be able to land this change without widening the constraint pre-emptively, and then in shelf_web_socket we can add a dependency override on the latest version of package:test (with the forwards compatible change).

Then, when shelf_web_socket is published, we can update the constraint here and publish again (after which point the override in shelf_web_socket can be removed).

That avoids publishing any regular dependency constraints in any packages with versions that aren't actually there yet (it will only be an override on the dev dependency in shelf_web_socket, which is fine).

WDYT?

[devoncarew]

That avoids publishing any regular dependency constraints in any packages with versions that aren't actually there yet (it will only be an override on the dev dependency in shelf_web_socket, which is fine).

Sounds great! Forward declaring the dep - even for something we control - does feel like crossing your fingers and hoping.

[devoncarew]

Is it expected here that the publish check fails? We just ignore for this package, but still use publishing automation after this lands?

 Package validation found the following potential issues:
  * Your dependency on "test_api" should allow more than one version. For example:
...

[jakemac53]

Is it expected here that the publish check fails? We just ignore for this package, but still use publishing automation after this lands?

Yes, we have to add the label to ignore warnings because we pin test_core and test_api.

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:test	1.25.11	ready to publish	test-v1.25.11
package:checks	0.3.1-wip	WIP (no publish necessary)
package:fake_async	1.3.2	already published at pub.dev
package:matcher	0.12.18-wip	WIP (no publish necessary)
package:test_api	0.7.4	already published at pub.dev
package:test_core	0.6.7	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.