Next major release: v5

[Belco90]

This is just an umbrella discussion to keep all ideas and necessary changes to be addressed in the next major release: eslint-plugin-testing-library v5

Changes in Shareable Configs

• add no-unnecessary-act to react config

Rules renaming

• no-debug --> no-debugging-utils

Add framework to the detection mechanism

Mario Beltrán: I think it would be interesting to be able to set which Testing Library framework you are using at the Shared Setting level rather than per rule (e.g. no-dom-import). Knowing which Testing Library framework is used across the whole plugin would make it easier for the users to set up the plugin, but also improve the way we can detect, report and fix errors.

With this shared setting, we could merge rules like await-async-utils and await-fire-event into a single one. Knowing which Testing Library framework is used would enable the plugin to report utils that have some particularities for specific frameworks, like fireEvent being async for Vue and Svelte, but not in others. It would give us the ability to detect behaviors across Testing Library packages with more granular control about different details for each framework.

This would make it easier to include new frameworks in the plugin too since ideally it would imply just including the new option and define its particularities for existing rules.

However, we need to define the proper structure to keep the info based on Testing Library frameworks. For example, which utils are async for each framework.

Auto enable some rules based on packages installed in the codebase

Mario Beltrán: Some existing ESLint plugins detect certain packages installed in the codebase (and even their versions). I think it would be really interesting to do have this mechanism in our plugin so we can auto-enable some rules based on packages found in the user's codebase:

• enable no-manual-cleanup if mocha, Jest, or Jasmine found
• enable prefer-user-event if user-event found

I don't think we don't need to check the version installed for the first approach.

---

Feel free to comment your own ideas to discuss what to implement in the next major! ✨

[MichaelDeBoey]

Add framework to the detection mechanism

How would you see this working when you are working with 2 testing libraries (for instance react & react-hooks or preact & preact-hooks)?

Auto enable some rules based on packages installed in the codebase

Do you have some examples of ESLint plugins doing this?
I think it's an interesting idea, but I also have some weird feelings about auto-enabling rules.

Only by default is what you're saying I think?

• enable prefer-user-event if user-event found

It's a best-practice to always use it, so this rule should sort of work as an incentive to add it to devDependencies I think.

Enabling it when the package is present is is definitely a good thing, but I think the incentive case is a good one to keep in mind too.
So in that case it would be "if present OR true", which just results to true (so always enable it)

[Belco90]

1. framework topic: in that particular case I guess we will have to define which frameworks exclude others (e.g. combining react and angular) and which can work together (e.g. combining react and react-hooks)
2. auto-detecting packages: it would be auto-enabled by default if the user didn't set anything related to that particular rule of course (otherwise, whatever the user sets is what we do). Some examples of auto-detection here:
   • eslint-plugin-react. You can set "version": "detect" so the plugin will figure it out for you and enable specific behaviors based on it.
   • eslint-plugin-node. It will use your node version specified in package.json for node/no-unsupported-features/* rules.
3. I don't like to enable user-event on shareable configs. It's a recommendation, indeed, but if the user doesn't have the package installed we are forcing them to do so. This is really painful in an existing code since it would mean having to refactor all existing fireEvent usages. That's why I think it would be better to enable it if the package is present so we can assume it's being used already.

[MichaelDeBoey]

we will have to define which frameworks exclude others

That will make it quiet complex I think

• eslint-plugin-react. You can set "version": "detect" so the plugin will figure it out for you and enable specific behaviors based on it.
• eslint-plugin-node. It will use your node version specified in package.json for node/no-unsupported-features/* rules.

When I find some time, I'll check this out to see if this seems a good idea to me and what pitfalls I think they can have

3. I don't like to enable user-event on shareable configs. It's a recommendation, indeed, but if the user doesn't have the package installed we are forcing them to do so. This is really painful in an existing code since it would mean having to refactor all existing fireEvent usages. That's why I think it would be better to enable it if the package is present so we can assume it's being used already.

My bad, I thought it was currently enabled by default, but it isn't.
Checking whether the user-event is installed and erroring when it is sounds a good idea then indeed. 👍
We should add some sort of a detect option by default in our configs for this, so people can still always disable/enable the rule if they want to.

[Belco90]

we will have to define which frameworks exclude others

That will make it quiet complex I think

I'm not sure if we actually would need to flag the excluded one but make that difference internally in the plugin. Ideally, you would only have to pick between angular, react, or vue (from current options). It shouldn't be necessary to specify react-hooks since that one would work differently on its own. I guess to the previous list we could add preact when available in officially in the plugin.

[Belco90]

Added Rules renaming section. I have more suggestions for this one, I'll try to fill it soon.