Remove meta.docs.category from core rules

[anikethsaha]

The version of ESLint you are using.
master, 7.2.0

The problem you want to solve.
#13382
as discussed, there seems to be some inconsistency among rules that can either belong to es6 category or other categories.
Also as there are other rules as well that support es6+ specs like rest-spread-spacing and others, so I guess it might lead to categories these rules according to their es version.

Your take on the correct solution to problem.
So I guess it would be better to have no category based on es version

Should these are the following ecmascript-6 category rules that should change their category to following new categories

• S : Stylistic Issues
• P : Possible Errors
• B : Best Practices

rule name	new category
arrow-body-style	B
arrow-parens	B
arrow-spacing	S
constructor-super	P
generator-star-spacing	S
no-class-assign	P
no-confusing-arrow	B
no-const-assign	P
no-dupe-class-members	P
no-duplicate-imports	P
no-new-symbol	P
no-restricted-exports	not sure, may be P ?
no-restricted-imports	same as 🔼 ?
no-this-before-super	P
no-useless-computed-key	B
no-useless-constructor	B
no-useless-rename	B
no-var	B
object-shorthand	B
prefer-arrow-callback	P
prefer-const	B
prefer-destructuring	B
prefer-numeric-literals	not sure
prefer-rest-params	B
prefer-spread	B
prefer-template	B
require-yield	B
rest-spread-spacing	B
sort-imports	S or B
symbol-description	B
template-curly-spacing	S
yield-star-spacing	S

thoughts ?

Are you willing to submit a pull request to implement this change?
Yes

PS: I guess I picked the wrong template, it should have been rule changes, to core label should be replaced with rule ?

[lydell]

Previous discussion: #7991

[anikethsaha]

Along with documentation changes, this would need changes in rules not in core. so I guess the core label can be removed.

[kaicataldo]

Along with documentation changes, this would need changes in rules not in core. so I guess the core label can be removed.

Can you explain what you mean by this?

[kaicataldo]

I agree that the ES6 category isn't particularly useful at this point and would love to see those rules categorized by more descriptive categories.

[anikethsaha]

Along with documentation changes, this would need changes in rules not in core. so I guess the core label can be removed.

Can you explain what you mean by this?

currently, this issue is labeled with core which I think can be removed as this might not require to change anything in the core. Just rule's category changes and the docs.

May be some tests might be changed.

[kaicataldo]

Oh, I see - that makes sense!

[ljharb]

A rule's category is part of its observable metadata, though, no?

[kaicataldo]

@ljharb Are you asking if this should be a breaking change or not? If so, I agree that we should publish this in a major release.

[anikethsaha]

Yeah, this would require changes in the init command I guess, so I think it can be breaking as that may lead to different config generation.

[ljharb]

It would also break any tools in the ecosystem that read the rule's category.

[anikethsaha]

There are some not sure and or in the table above in the issue description.

Would appreciate some inputs/thoughts on them.

[nzakas]

I’d recommend a slight change and suggest we use the rule type instead of categories. The rule types are errors, suggestions, and layout: https://eslint.org/docs/user-guide/command-line-interface#fix-type

We can pretty up the headings as Possible Errors, Suggestions, and Code Spacing, or whatever else makes sense. I’d just like us to stick with the three types we already have for simplicity.

[mdjermanovic]

I think it might be good to have more than three categories.

For example, no-with and no-continue are both type: "suggestion", but there should be a difference because one enforces a best practice, while the other is only stylistic.

[nzakas]

@mdjermanovic Im not sure that making that distinction is important at this point in ESLint’s lifecycle. I’d like to get away from the term “best practices,” as well, so we can stay a little more neutral. We already have “eslint:recommended” to signify what we believe are the most important rules across the board.

Plus, if we stick with using the rule type on the page, this is no longer a breaking change because the meta data isn’t changing. Also, there’s a nice correlation with the use of —fix-type.

[nvmnghia]

Can someone explain why prefer-destructuring is a Best practice? I see that it works for multiple variables, like:

const { a, b, c, d } = object;

But this one is illegible:

const { a } = object;

Can a linter detect that there's just one variable, and don't enforce the rule?

[anikethsaha]

IMO, prefer-destructuring is the best practice because,

• Less code
• more code readability.
• works well for defaults (code quantity is quite less when destructuring)

and about the code you mentioned,
the object should have a property a otherwise it would be undefined

eg

You can refer the docs or this article for more details

[btmills]

As part of this change for ESLint v8.0.0, we also want to remove the category key from core rules so it’s clear that users shouldn’t be relying on it.

[ljharb]

This will probably create a lot of churn for the Airbnb style guide, since it provides entry points for each category, and groups config by category.