Document freezing of stylistic rules

My proposal may seem too loud to someone, but it is discussion.

Our main problem is that we can never satisfy stylistic preferences. There will always be someone who wants an extra space or line break. Stylistic rules grow endlessly and create more and more problems. It’s getting harder and harder to maintain.

Eslint has https://eslint.org/blog/2020/05/changes-to-rules-policies and says:

Stylistic rules are frozen - we won’t be adding any more options to stylistic rules. We’ve learned that there’s no way to satisfy everyone’s personal preferences, and most of the rules already have a lot of difficult-to-understand options. Stylistic rules are those related to spacing, conventions, and generally anything that does not highlight an error or a better way to do something. Update 2021-01-29: We clarified in the README that we will still support newly-added ECMAScript features.

Honestly, I think we should do the same.

Currently prettier does a good job. I see no reasons to not use prettier. And most developers have long seen the benefits of using formatters.

Yes, some stylistic rules can still be helpful - order of properties (we have a plugin for this), force using newlines in some places (we can reduce them to a minimum options). I think we can put together a list of style rules here and discuss them.

My opinion has always been: want your preferred formatting - write your rule/plugin.

I don’t think we should bear the burden of maintaining due to some developers who want to have an extra space. I don’t want to show disrespect for someone’s preferences.

I think it’s time to say that stylistics rules are outdated. They were all created when we didn’t have good formatters. Enough time has passed since that time and a lot has changed.

My proposal:

• Collect stylistics rules here and discussion them, maybe divide them on two sides - can be solved formatter and can’t be not solved formatter.
• Create/update documentation about rules police about stylistics rules.
• Freeze stylistics rules.
• Close all issues related to stylistics rules.

@stylelint/contributors

[jeddy3]

@alexander-akait Thanks for writing up the proposal and for starting the discussion.

@nosilleg Thanks for doing the legwork and cataloguing the rules.

Thank you everyone else for chiming in. The consensus is to freeze the stylistic rules.

I agree too. It’ll also help us communicate how a pretty printer like Prettier and a linter like Stylelint are complementary tools that can be used together, and address a misconception in the community that it’s either/or. We can better emphasize the error checking and limiting rules — the latter of which are unique to Stylelint and very useful for authoring consistent CSS.

First, we should update our docs and then close any related issues.

Later down the line, we can deprecate the frozen rules and eventually remove them. I’ll open a follow-up issue for the deprecation. It’s at this point, we should remove the rules from our standard config.

At any point in the process, the community is welcome to migrate the rules into an unofficial plugin pack.

[jeddy3]

I take it to mean that the stylistic rules won’t be touched (including bug fixes), will be deprecated and then eventually removed. People can always migrate a rule to a plugin to fix bugs or add options. Better to have a clean slate down the line, than some halfway house (i.e. some stylistic rules, but not for new language features) as we’re a smaller project than ESLint with limited resources.

Shall we document this?

Good idea. I can open a pull request.