Rename recommended config

[Belco90]

Motivated by this comment I want to propose renaming recommended config to dom.

I picked that name because is the usual config included in an ESLint plugin, but it doesn't look like proper name and seems misleading. I have seen some people too configuring recommended + react or another framework, so the name can be definitely improved.

My proposal then is to rename recommended to dom so 1) it's obvious it's not a recommended one in general, but specific one for DOM Testing Library and 2) it makes clearer the fact you don't need to enable that one together with another one for a Testing Library framework.

I can address this one myself tomorrow (including doc updates) and add it to v4, but I'd like to know your opinion first.

[gndelia]

I am still having issues to understand the meaning by saying that a rule is recommended (or now, dom as suggested)

My thought was that if a rule was recommended, it was enabled by default if the plugin was configured in the user-land in the .eslintrc with

{
  "extends": ["plugin:testing-library/recommended"]
}`

Like, any user can configure the rules they want, but the plugin offers a good "default" with what people behind it consider should be good practices everyone should follow (hence they are recommended by the devs here)

So in that sense

1. it's obvious it's not a recommended one in general, but specific one for DOM Testing Library

It's obvious as it is recommended by this library in particular

and

) it makes clearer the fact you don't need to enable that one together with another one for a Testing Library framework.

I still don't see how it affects that.

But now with your comment here and the fact that this issue was created, it seems there's another meaning implicit in recommended (and/or in dom) that I am missing.

What's the meaning it's expected to be understood when a rule is recommended (or a dom rule in this case?)

[nickserv]

It's supposed to be used for the default recommended ruleset, just like eslint:recommended. However in this case, despite us using the recommended name, that's not really what the recommended config is for. Technically we recommend all configs, but it depends on the library, recommended is not necessarily the best as it's specifically for dom-testing-library. I think @Belco90's suggestions would clear up this confusion.

[gndelia]

Just to clarify if I understood correctly when you mean

but it depends on the library,

you are referring to the different implementations right (react, angular, vue)? I haven't used any of them, except for the react implementation, so sometimes I forgot they are two different things 😄

So in that sense, the rules are for the general dom-testing-library and by switching from recommended to dom we'd enforce that.

Thanks in advance 😄

[Belco90]

I think the problem is this plugin is targeting different Testing Library frameworks. Usually ESLint plugins target a specific library so is pretty clear what the recommended config means.

Here I'm not so sure now about what recommended means or should mean:

• recommended rule in general for all Testing Library frameworks? Fair enough, but then a "react" badge in the configs should mean "this is a rule for React in particular". This is not the current case as we have rules with both "recommended" and "react" configs. With this one, for a Testing Library framework on top of DOM (like React one) you would have to setup recommended one + those particular ones for React.
• recommended rule for the base Testing Library framework, which is DOM one. This was my intention, but I must admit it was really bad executed. With this approach you just pick the config for the Testing Library you are using: recommended or react, but not both.

The thing is the plugin is mixing these two approaches so it's confusing. I prefer then to rename recommended to dom so users know they only need to pick and enable one of them for the Testing Library package they use.

[nickserv]

By the way, what does the recommended boolean in the rule sources do? In the other ESLint plugins I've seen, these were used to generate the readme table and configs, but we're doing that manually here, so I'm not sure what it's for.

[gndelia]

I see. Thanks for the detailed explanation to both 😃 ; indeed there are some mixing concerns and dom seems an improvement on that.

We could add to the docs that dom refers to recommended rules regardless of the library implementation;

If a rule has the dom badge, should we then skip the badge for react, vue, etc ?

I understand that they won't be required, as those should be used for rules that are specific to those implementations.

[Belco90]

By the way, what does the recommended boolean in the rule sources do? In the other ESLint plugins I've seen, these were used to generate the readme table and configs, but we're doing that manually here, so I'm not sure what it's for.

To be honest: I thought that would happen automagically when I created the plugin but it's obviously not 😂 . I'd like to use that bool (and some extra for each config) for autogenerating that in the future.

[Belco90]

We could add to the docs that dom refers to recommended rules regardless of the library implementation;

If a rule has the dom badge, should we then skip the badge for react, vue, etc ?

I understand that they won't be required, as those should be used for rules that are specific to those implementations.

I want to avoid this actually. Testing Library packages like cypress or react-native are not built on top of DOM exactly. So I'd leave as many badges as needed for rules recommended on dom, angular, react and vue so the Configurations column would work as "recommended for all these packages".

That doesn't mean we need to do it manually in the plugin code. We can leave it as now and inherit vue config from dom + its specific recommended rules (I picked Vue as example because it has one rule which is necessary only for that package).

[nickserv]

By the way, what does the recommended boolean in the rule sources do? In the other ESLint plugins I've seen, these were used to generate the readme table and configs, but we're doing that manually here, so I'm not sure what it's for.

To be honest: I thought that would happen automagically when I created the plugin but it's obviously not 😂 . I'd like to use that bool (and some extra for each config) for autogenerating that in the future.

I don't think that system would work for us with multiple configs, I'd still like to figure out some way to declare the configs a rule belongs to in the rule so it can be used to generate all the configs and the table (not just for dom/recommended). That being said we're not the only ESLint package with multiple configs, so I wonder if there's already an example of this out there.

[timdeschryver]

+1 for the rename to /dom.

It should be possible generate the configs based on the rules.
I was thinking about implementing it in another eslint repo, and it turns it it's fairly simple. (see timdeschryver/eslint-plugin-ngrx#35 as a ref).

[nickserv]

I also did something similar here, totally forgot 😅 testing-library/eslint-plugin-jest-dom#4

Do we want to make these automation changes before or with the config renaming?

[Belco90]

I guess we can address it after this PR? It's a chore change so it won't mean anything for final user, while this config renaming is definitely a change for users. If you are happy with it, I'm gonna rename the config and then I can address the automation thing in a later step.

[nickserv]

I might be interested in giving it a shot, but I guess you're right that the order doesn't matter much. We're not changing too many things in the v4 configs yet anyway.

[github-actions]

🎉 This issue has been resolved in version 4.0.0-beta.1 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀