testing-library / eslint-plugin-testing-library

ESLint plugin to follow best practices and anticipate common mistakes when writing tests with Testing Library
https://npm.im/eslint-plugin-testing-library
MIT License
992 stars 142 forks source link

feat: cleanup main types #964

Open MichaelDeBoey opened 5 days ago

MichaelDeBoey commented 5 days ago

Follow-up of #963

CC/ @G-Rath

codecov[bot] commented 5 days ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.32%. Comparing base (93a6ab9) to head (a5ba37b). Report is 27 commits behind head on main.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #964 +/- ## ========================================== + Coverage 96.23% 96.32% +0.09% ========================================== Files 44 46 +2 Lines 2419 2479 +60 Branches 1000 1017 +17 ========================================== + Hits 2328 2388 +60 Misses 91 91 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


🚨 Try these New Features:

G-Rath commented 5 days ago

I don't really see this as strictly better - the types as they are pretty straightforward and maintainable as they are imo, and I in particular like having the configs written out individually to make it clear what is available without having to mentally unroll some type logic.

Unlike your PRs to the other plugins, this one does has a slight advantage due to the number of configs, but given I don't expect this to need changing pretty much ever (aside from when the flat configs go away which'll half the number of properties), I still wouldn't say it's worth landing.

At the very least, this is not a "feat" or a "fix"

MichaelDeBoey commented 5 days ago

@G-Rath We're also using TSESLint's types here, which is a dependency we already have

If we use ESLint's dependency, we would need to add @types/eslint to the dependencies in package.json to work correctly

G-Rath commented 5 days ago

@MichaelDeBoey you'll already need @types/eslint as a dependency if you're type-checking eslint.config.js on v8, and ESLint v9 ships with its own types that are compatible with these ones, so that shouldn't be an issue

MichaelDeBoey commented 5 days ago

@G-Rath with these changes, you don't need @types/eslint anymore when having ESLint v8

G-Rath commented 5 days ago

@MichaelDeBoey do you have an actual example of a project where you are getting an error with these types because @types/eslint isn't present?

Because I'm willing to bet most people will have @types/eslint available if they're using v8 since to have a properly typed eslint.config.js you should be typing your export as a flat config (so you either need to source that type from @types/eslint or @typescript-eslint), and most plugins I've seen exporting types are using types from eslint rather than @typescript-eslint.

So the only situation I can think of where this'd come up is if you're running just this plugin with ESLint v8 which seems kind of weird - why would you go to all the trouble of setting up ESLint just to apply linting rules for your testing code?

Meanwhile, everyone is busy upgrading to ESLint v9 which as mentioned before is now typed - so I feel the audience for this is very niche (and that ultimately installing @types/eslint is not a big deal)