Update package:collection for the new strict_top_level_inference lint

[devoncarew]

• update package:collection readme to get analysis to run

---

• 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

Breaking changes ⚠️

Package	Change	Current Version	New Version	Needed Version	Looking good?
collection	Breaking	1.19.1	1.20.0-wip	2.0.0 Got "1.20.0-wip" expected >= "2.0.0" (breaking changes)	⚠️

This check can be disabled by tagging the PR with skip-breaking-check.

Changelog Entry ✔️

Package	Changed Files

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

Coverage ⚠️

File	Coverage
pkgs/collection/lib/src/unmodifiable_wrappers.dart	💔 75 % ⬇️ 3 %

This check for test coverage is informational (issues shown here will not fail the PR).

This check can be disabled by tagging the PR with skip-coverage-check.

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols

License Headers ✔️

// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

[devoncarew]

From the new strict_top_level_inference lint, we see two sets of issues here:

   info - lib/src/unmodifiable_wrappers.dart:199:7 - Missing type annotation. Try adding a type annotation. - strict_top_level_inference
   info - lib/src/unmodifiable_wrappers.dart:203:7 - Missing type annotation. Try adding a type annotation. - strict_top_level_inference

That's from https://github.com/dart-lang/core/blob/main/pkgs/collection/lib/src/unmodifiable_wrappers.dart#L199:

  /// Throws an [UnsupportedError];
  /// operations that change the map are disallowed.
  set first(_) => _throw();

  /// Throws an [UnsupportedError];
  /// operations that change the map are disallowed.
  set last(_) => _throw();

Here, I don't know what purpose first and last are for; they're not overrides from Map.

The next set of issues:

   info - test/extensions_test.dart:2228:20 - Missing type annotation. Try adding a type annotation. - strict_top_level_inference
   info - test/extensions_test.dart:2228:23 - Missing type annotation. Try adding a type annotation. - strict_top_level_inference
   info - test/extensions_test.dart:2228:27 - Missing type annotation. Try adding a type annotation. - strict_top_level_inference

are from https://github.com/dart-lang/core/blob/main/pkgs/collection/test/extensions_test.dart#L2228:

Never unreachable([_, __, ___]) => fail('Unreachable');

Perhaps we should not include wildcard variables in the lint?

cc @lrhn, @natebosch, @srawlins

[lrhn]

The setters should just be removed from the Map wrapper, they're mistakes.

Other than that, we could exclude wildcards, but since the lint should only trigger if you don't inherit a type, I think the method should actually be explicit about its types.

Or, more relevantly, since it's in the test directory, it is not public API, and it should probably just be private.
Or the entire test directory should be exempt. (Don't know if we'd have to make a second lint off you want to pour it back in.)

[jakemac53]

Technically this is breaking (statically) to remove these?

We might want to just deprecate them 🤷‍♂️ . But should at least verify we don't know of any usages (I would expect none though since nobody really uses this type directly in APIs).

[devoncarew]

I'm happy to deprecate first and check for any real usage asynchronously.

[lrhn]

If we do a proper 3.0 release soon-ish, they can go away there.

[lrhn]

If we do a proper 3.0 release soon-ish, they can go away there.

[jakemac53]

If we do a proper 3.0 release soon-ish, they can go away there.

Note that this package is pinned by flutter so this is probably never going to be justified.... it will cause a very large amount of ecosystem churn and pain. Unless of course flutter stops pinning packages :)