Remove `meta.docs.category` from core rules

The version of ESLint you are using. master, 7.2.0

The problem you want to solve. https://github.com/eslint/eslint/issues/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 ?

[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

[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.