Splitting 'expect' into targeted rules

[JoshuaKGoldberg]

tl;dr

The expect-type/expect rule is quite large and contains multiple feature areas. I propose we deprecate (not delete, for now) it and create standalone rules for each of those feature areas.

Context

I first joined as a maintainer of eslint-plugin-expect-type in August of 2021. I intentionally did not make any major changes for many months after that, to make sure I wasn't getting in the way of any existing community momentum. Back then this package supported:

• $ExpectError
• $ExpectType
• $ExpectTypeSnapshot
• A recommended config containing the sole expect rule that supports those comments

In the year and change since, the following features have been brought up:

• ^? Twoslash assertions: implemented in Add twoslash support #47
• // @ts-(expect-error|ignore) diagnostic code/text matching: Checking errors via @ts-expect-error? #65

The surface area of what this plugin is being asked to do is getting larger than just "expect type" assertions. Arguably, given $ExpectError, it always was.

expect.ts is currently at over 600 lines. It includes 8 separate message IDs, support for parsing both ^? and $ comments, and file snapshots.

Proposal

I propose this package be split up into one rule per area of functionality, each set to error in the recommended config:

• expect-type/equals*: ^?, $ExpectType, and $ExpectTypeSnapshot
• expect-type/error: @ts-(expect-error|ignore) and $ExpectError

*I'm not confident on this name. expect-type/to-be? expect-type/is? Would very much like to hear more alternatives 🤔...

Deprecating expect

Existing users ... expect that expect exists and works. While it may be meta.replacedBy other rules, it should stick around for a while. My timeline proposal would be roughly:

1. Implement this refactor of new rules, extracting shared logic into shared helpers
2. Fix major bugs currently impacting the package (e.g. Running eslint without --fix still updates snapshots #14, Diff fails on Windows #63, Tabs are not considered whitespace for checking a comment's line index #64)
3. Wait a few more months to gain user feedback & repeat step 2 as needed
4. Release a 1.0.0 with it deleted as a breaking change

---

I'd love to hear thoughts from the TypeScript community! What do you all think? Especially, but not limited to:

• Is the idea of splitting up the one rule into two particularly convenient or inconvenient to you?
• Are there other feature areas you'd like to see this plugin support?

[danvk]

How much of the win here would come from splitting the single expect rule vs. splitting up the large expect.ts file? Presumably we could do the latter without requiring any sort of migration for users.

[JoshuaKGoldberg]

I'd say both are relevant, yeah. My intuition from other large rules is that the user experience of putting many options on one rule is the biggest concern.

[JoshuaKGoldberg]

Just following up: agreed with @danvk. Users are perfectly happy with the one expect so far and nobody has spoken out in favor of splitting it up. Let's keep it to one rule for now, and just refactor its internals. Thanks!

Refactor PR here: #117