Introduce an analyzer plugin for the test package.

[srawlins]

Note: I'm not strongly suggesting this PR be accepted today as is. But I'm offering it up.

As part of the new analyzer plugin system, I'd like to offer some first-party-maintained analyzer plugins. I don't intend for us to maintain complex plugins necessarily. But good bang-for-our-buck plugins have some great benefits:

• We provide examples of analyzer plugins for others to crib. This plugin clocks in at 160 lines of code, offering a static warning rule and a quick fix.
• We provide value to customers of our first-party packages, like the test package.

If there are other static analyses that the team has dreamed of, I'd love to evaluate them for complexity and possibly add more static analyses to this plugin.

Again, we don't need to land this any time soon, if the team is hesitant to check this in, maintain it, etc. The new analyzer system is not officially released, and the API is probably not super stable. I'm opening this PR for the discussion, and to have URL to point to as a real world analyzer plugin example.

[github-actions]

PR Health

Changelog Entry ✔️

Package	Changed Files

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

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

[jakemac53]

We should probably add something to the package:test readme as well, informing users of this plugin and how to enable it for their project.

[srawlins]

Since we are very "soft launching" analyzer plugins ATM, I think we don't want to advertise it there yet. WDYT?

[jakemac53]

Up to you I guess, but we won't get usage if we don't advertise it

[FMorschel]

I've not yet read the whole changes, but what about an annotation on Matchers to specify what types we are expecting to handle and a diagnostic if they aren't being tested against them?

I'd love to contribute to it if this is something you are interested.

[srawlins]

but what about an annotation on Matchers to specify what types we are expecting to handle and a diagnostic if they aren't being tested against them?

That's a fun idea, you could open an issue against this repo.

For first-party matchers in the matcher package, I don't think it would be worth the extra complexity. So the feature would be for custom matchers implemented outside of the matcher and test packages.

[srawlins]

OK I'd love to land this actually. Esp with Dart 3.10 out today. Anyone know what the failing Publish check is about? I can't make heads or tails of it.

[kevmoo]

@srawlins

[srawlins]

How did you find that, Kevin? I grep the failed Publish CI task for 'error' and nothing :( Just 300 lines of 'Found published package at Directory'.

[kevmoo]

How did you find that, Kevin? I grep the failed Publish CI task for 'error' and nothing :( Just 300 lines of 'Found published package at Directory'.

We need to be more clear in these dumps. I just have experience digging 😁

[kevmoo]

[srawlins]

How do I respond to those CI checks with "Optional advice is duly noted"? :D

[kevmoo]

Add the ignore label about package warnings – or add the missing bits to the pubspec 😄

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:checks	0.3.2-wip	WIP (no publish necessary)
package:fake_async	1.3.3	already published at pub.dev
package:matcher	0.12.18	already published at pub.dev
package:test	1.28.0	already published at pub.dev
package:test_analyzer_plugin	0.1.0	ready to publish	test_analyzer_plugin-v0.1.0
package:test_api	0.7.8	already published at pub.dev
package:test_core	0.6.14	already published at pub.dev
package:test_descriptor	2.0.2	already published at pub.dev
package:test_process	2.1.1	already published at pub.dev

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

[srawlins]

OK all checks are passing; this is ready for review 😁