Create the 8-rules plugin (for the ones not yet handled by Prettier)

[Mouvedia]

What is the problem you're trying to solve?

Not having ppl stuck on 14.x.x if they depend on the dropped rules.

What solution would you like to see?

Create a repository and the corresponding npm package for the plugin.

see

• Remove Node.js 12 support #6311 (comment)
• Remove Node.js 12 support #6311 (comment)

followup: find an official maintainer (optional)

[ybiquitous]

@Mouvedia Thanks for opening a new issue for the discussion.

The 8-rules is follows:

stylelint/docs/user-guide/rules.md

Lines 301 to 330 in 6683e1e

	### Not handled by pretty printers
	#### Value
	- [`value-keyword-case`](../../lib/rules/value-keyword-case/README.md): Specify lowercase or uppercase for keywords values (Autofixable).
	#### Function
	- [`function-name-case`](../../lib/rules/function-name-case/README.md): Specify lowercase or uppercase for function names (Autofixable).
	#### Custom property
	- [`custom-property-empty-line-before`](../../lib/rules/custom-property-empty-line-before/README.md): Require or disallow an empty line before custom properties (Autofixable).
	#### Selector
	- [`selector-type-case`](../../lib/rules/selector-type-case/README.md): Specify lowercase or uppercase for type selectors (Autofixable).
	#### Rule
	- [`rule-empty-line-before`](../../lib/rules/rule-empty-line-before/README.md): Require or disallow an empty line before rules (Autofixable).
	#### At-rule
	- [`at-rule-empty-line-before`](../../lib/rules/at-rule-empty-line-before/README.md): Require or disallow an empty line before at-rules (Autofixable).
	#### Comment
	- [`comment-empty-line-before`](../../lib/rules/comment-empty-line-before/README.md): Require or disallow an empty line before comments (Autofixable).
	- [`comment-whitespace-inside`](../../lib/rules/comment-whitespace-inside/README.md): Require or disallow whitespace on the inside of comment markers (Autofixable).

[Mouvedia]

Also we need to review whether the options of the other stylistic rules are properly covered by Prettier.
If not we either open PRs on Prettier side or just add more rules to the plugin.

[ybiquitous]

I guess it's a big problem how long we will maintain that new repository.

[ybiquitous]

Considering our maintainers' fewer resources, I believe it's better to avoid maintaining the plugin repository as possible — for example, archive the repo to prevent issue triage, etc.

[Mouvedia]

Here's how I would recommend to do it:

1. review options
2. create github repo under @stylelint (without issues)
3. release as β on npm
4. find a maintainer for the plugin
5. transfer the repo to the maintainer
6. release 1.0.0 on npm on the maintainer scope
7. migrate all relevant closed stylelint issues to the new repo

1, 2, 3, 5 and 7 are our responsibility; I am not sure whether 4 is ours.

[ybiquitous]

Sounds good. If a maintainer cannot be found, the plugin will remain β, right?

[Mouvedia]

If a maintainer cannot be found, the plugin will remain β, right?

I guess? It's just my recommendation.
If you put a disclaimer in the README you will find a maintainer in no time.
The priority is parity for now.

[jeddy3]

@Mouvedia You're correct in wanting to ensure as smooth a migration as possible for everyone.

We intended initially to discuss in #6342 which of the stylistic rules to deprecate, but we never got around to it. I've picked up the discussion there.