feat: add rules for toBePressed, toBePartiallyPressed, toBePartiallyChecked matchers

[shamrt-v]

What:

Add three new ESLint rules for recent jest-dom matchers:

• prefer-pressed — suggests toBePressed() / not.toBePressed() instead of manual aria-pressed attribute checks
• prefer-partially-pressed — suggests toBePartiallyPressed() instead of toHaveAttribute('aria-pressed', 'mixed')
• prefer-partially-checked — suggests toBePartiallyChecked() instead of toHaveAttribute('aria-checked', 'mixed')

All three rules are included in the all config but excluded from recommended to avoid breaking changes.

Why:

jest-dom v6.7.0+ added toBePressed and toBePartiallyPressed matchers, and toBePartiallyChecked has existed for years — but eslint-plugin-jest-dom had no rules to guide users toward them.

How:

• prefer-pressed reuses the existing createBannedAttributeRule factory (same pattern as prefer-checked)
• Created a new createPartiallyBannedAttributeRule factory for the two "partially" rules, targeting only the "mixed" attribute value via toHaveAttribute/toHaveProperty selectors
• All rules include auto-fix support
• New rules are filtered out of the recommended config via a newRules exclusion list in src/index.js

Note

This PR depends on #420 (fix/prefer-checked-mixed-value), which adds excludeValues support to createBannedAttributeRule. Both prefer-pressed and prefer-checked use excludeValues: ["mixed"] to avoid incorrectly flagging aria-pressed="mixed" / aria-checked="mixed". Merge #420 first, then rebase this branch.

Checklist:

• Documentation
• Tests
• Ready to be merged
  

Testing Instructions

1. npm install && npm test — all 586 tests should pass
2. Create a test file with these patterns and verify the rules fire and auto-fix:

   expect(el).toHaveAttribute('aria-pressed', 'true')   // → toBePressed()
   expect(el).toHaveAttribute('aria-pressed', 'mixed')  // → toBePartiallyPressed()
   expect(el).toHaveAttribute('aria-checked', 'mixed')  // → toBePartiallyChecked()

3. Verify aria-pressed="mixed" is not flagged by prefer-pressed

[G-Rath]

Yeah changing the configs is a breaking change, so please revert that - it would also be good if you can cherry-pick out the bug fix into its own PR since that should be landable on its own.

Also just FYI we're currently blocked on releasing new versions until @benmonro gets the pipeline set back up (see #417), so while I'm happy to review PRs, I may hold off landing them depending on the changes to avoid having too many unreleased changes

[shamrt-v]

it would also be good if you can cherry-pick out the bug fix into its own PR

Alrighty. Done: #420

[G-Rath]

Thanks, I've landed #420.

For the "partially" support though I'm not sure if they need dedicated rules, since the point of them is "use this dedicated matcher, rather than a generic attribute check" - I don't really see a situation where someone would prefer using e.g. toBeChecked but not toBePartiallyChecked?

I wouldn't be surprised if it's more complicated to implement that due to the way this plugin uses functions to build its rules, but I'd be keen to see more of what it'd actually look like to go that route before deciding if we should add new rules instead.

In the meantime, I'd be happy to add prefer-pressed since we'll end up with that either way and we can just have it ignore toBePartiallyPressed like we're now doing with prefer-checked.

Either way fwiw new rules should generally have their own PRs unless they have a lot of overlap in their implementation, to make it easier to review and so that they have their own changelog entry.