Document stylistic plugin in migration guide

[elirasza]

Hello, just to let you know I have created and published a plugin containing all the stylistic rules that were removed in 15.0.0 : stylelint-stylistic. It still under development but everything should work as before :)

I saw in your migration guide you wanted to be noticed once such a package were avaiblable, so here we are !

[ybiquitous]

@elirasza Great! We appreciate your work! 👏🏼

Could you add your stylistic plugins to our awesome list if you don't mind?

[elirasza]

Thanks for the quick reply. I have sent a PR : stylelint/awesome-stylelint#52 !

[ybiquitous]

The awesome list now includes the stylelint-stylistic plugin!

I'll make this issue open for a while so that people can easily find such a plugin that includes deprecated stylistic rules.

[kerryj89]

I just now saw this, thanks so much @elirasza! It might be nice if this were part of the migration notes but I guess it's not "official" and vetted enough to be recommend there? This would've made it so much easier. Prettier was really barebones when it came to options (by design I realize).

[ybiquitous]

@kerryj89 Nice catch. I agree we would recommend this plugin in the migration guide. 👍🏼
If you're interested in contributing to Stylelint, could you try PR to improve the migration guide?

[GergelyKalmar]

I'd like to mention that the plugin is not very compliance department-friendly at the moment – the repo is owned by a user that is brand new and was seemingly created with the purpose of publishing that one package. From a supply chain security perspective it's not nearly as assuring as the current built-in features that come with Stylelint itself.

[cenfun]

Good job!
stylistic-rules is one of the best features of stylelint, but unfortunately, stylistic rules were deprecated in stylelint v15 by Prettier, don't understand why, because

• We don't need to use Prettier because StyleLint and Eslint have done a good job in code formatter
• We will never use Prettier because so many tools are loaded in the front-end development, conflicts and troubles get more and perfornance gets worse

Thanks to this plugin for helping us get back to using stylistic-rules

[elirasza]

I'm glad to help ! This is indeed my first take on open-source, so this account is brand new. I am more used to my company's proprietary codebases so I'm still a noob in understanding how the community works.

I also did not quite understand the underlying reasons of why stylistic rules were removed, but I'd say it does make sense from a single-responsibility point of view : keep stylelint a strict linter, while betting on plugins or other tools for formatting.

Maybe an "official" stylistic plugin would have been a good compromise, but maybe is it not in the stylelint team priorities ?

[cenfun]

Actually stylelint becomes even more useless without stylstic-rules, so we also hope that stylstic-rules will be an official plugin.
As we know, stylstic-rules and Prettier have some conflicts, but this should not cause stylstic-rules to be retired, and then need to use another additional tool. We should resolve these conflicts in a mutually beneficial way.

[ybiquitous]

We have needed to focus on linter not formatter since we have limited resources (quite a few volunteers to maintain the project). If we provided an official stylistic plugin, it would not be much different from maintaining the built-in rules as before.

Therefore, we determined to want the community's help. If you're interested in the background, please look at #5674, which enables us to close quite many bug reports or feature requests.

[cenfun]

I think good code formatting (style) is part of the linter. like eslint formatting rules with --fix done good job on formatter. however, we also understand the problem of maintenance, and thank you for doing a very good job

[firefoxic]

Unfortunately, I'm a little late with this message. But if anyone is interested, there is another plugin — stylelint-codeguide. Just wanted to at least a month to test on working projects — no problems.

I plan to expand the list of rules. At least I want to control spaces around the slash (#6530), which is necessary for my students.

Also would like to get rid of babel, but will have to wait until stylelint is rewritten to esm. But that's pretty easy, unlike the grand plan to rewrite tests from jest to node:test.

[firefoxic]

While writing, I forgot why I came :)
I wanted to clarify, do I have to specify in the license the authors of the rules used in the plugin? Or is it a matter of course, since the rules are taken from Stylelint itself?

[ybiquitous]

do I have to specify in the license the authors of the rules used in the plugin?

It should be recommended, but it seems difficult actually. To be honest, I guess it's not required.

[dbatiste]

I understand that it's a maintenance issue, and I am grateful for having stylelint since it's helped greatly.

I also think it makes sense for these rules to be part of the linter. We use a lot of these rules in a lot of projects and using Prettier isn't going to fly, so we'll be faced with using this plugin containing the stylistic rules, or copying them into our config (which unfortunately I just completed). Closing the issues just means people are going to have to raise them again somewhere else, wherever these stylistic rules find a home.

[alexander-akait]

Someone can provide why prettier is bad choice and why? Will be great to see examples of code, linter is for linting, not for formatting, dropping them allow for us to focus on more real problems/improvements in your code, I don't think it really makes sense where you have space(s)/newline(s) when you code, for examples, contains broken color functions or bad color or something else bad

[alexander-akait]

You should focus on what your write, not how you write

[dbatiste]

Prettier is an opinionated formatter. In all likelihood our formatting will not be inline with what Prettier produces, but that aside, introducing it into our tooling for 100s of projects and developers that currently use stylelint would be incredibly disruptive. I tend to think it's fine for the linter to enforce stylistic rules.

[alexander-akait]

@dbatiste Have you already tried it? Because I want to see real examples of where he is bad and what you want to improve, also prettier supports plugins, so you can just extends CSS printer and add extra space/newline, it will be faster and easier to maintain and give a lot more benefits

[GergelyKalmar]

I tried to work with both Stylelint stylistic rules and Prettier as well. The way Prettier works is very different from how Stylelint works though. Prettier is incompatible with most projects that are already using Stylelint. On one hand, it is opinionated, which means that there are very few configuration options compared to what Stylelint offers. Entire projects would need to be re-formatted once somebody switched over to using Prettier. On the other hand it is usually something you would run on your code (similar to Black in the Python ecosystem) – it doesn't give you errors on a per-line basis like Stylelint does. Currently it is also lacking some important features like showing a diff of changes (see prettier/prettier#6885), which can cause problems that we do not have when using Stylelint.

FWIW in the Python ecosystem pretty much all linters have formatting/style warnings (see flake8, pylint or ruff), despite the existence of an opinionated formatter like Black. The same is true for the JavaScript ecosystem, ESLint comes with a lot of highly configurable stylistic rules (despite Prettier's existence).

I agree with the others that deprecating these rules is going to cause a big headache for many. I would strongly prefer that the rules are kept within Stylelint. I also acknowledge that this can be a big maintenance burden, but I believe that soft-freezing these features (similar to how ESLint did it) would be a much better tradeoff. After all, the current rules are working fine, and I think the community would prefer keeping them in a frozen state as opposed to losing them entirely.

[kerryj89]

@dbatiste Have you already tried it? Because I want to see real examples of where he is bad and what you want to improve, also prettier supports plugins, so you can just extends CSS printer and add extra space/newline, it will be faster and easier to maintain and give a lot more benefits

I tried it here #6619 (comment) and after seeing what it did to my Scss I decided not to use it. The big one for me was that it was removing whitespacing where it makes sense to have it (value alignment, e.g. grid columns, long calc(), gradients) amongst other issues. Thankfully, there are now Stylelint plugins that exist to bring these CSS/Sass-centric opinionations back whereas Prettier's generalized approach would not have worked.

[Mouvedia]

IMHO this issue should be about the steps required to migrate elirasza/stylelint-stylistic to stylelint/stylelint-config-stylistic. Of course, @elirasza needs to be vetted as a safeguard and the plugin itself reviewed.
The goal being that such a critical plugin should be under our supervision if it already has an official maintainer.

[elirasza]

I'm all for it, my fork was only to have something working in the mean time. I'd be glad to give the ownership to someone more active and better-known.

[Mouvedia]

I'd be glad to give the ownership to someone more active and better-known.

I was proposing that you continue maintaining the plugin under the stylelint scope, not that you relinquish it.
Here's an example of something that it would facilitate: the transfer of issues that were closed because they requested changes to deprecated/stylistic rules.

[ybiquitous]

Would anyone be passionate about actively maintaining the repository (e.g., stylelint/stylelint-config-stylistic) if our owners created it?

/cc @stylelint/owners

[ota-meshi]

I plan to use the stylelint-stylistic plugin, so I'm hoping someone will maintain it, but I don't think it has to be in the organization. The plugin has already been published and can be used by anyone.
If @elirasza wants to stop maintaining the plugin, we may need to find a new maintainer like we did with postcss-css-in-js.

[firefoxic]

I'm not sure if this is appropriate, but I don't want to stop maintaining my plugin 👀

[Mouvedia]

All we are discussing will be really relevant in the next major release cycle.
There's one advantage of having it under stylelint/: you two could collaborate on the maintenance efforts if both plugins compete for the same purpose.

[firefoxic]

I really don't understand why it was necessary to remove these rules and then return them to the organization as a plugin 🤭

Wouldn't it have been easier not to remove them? 👀

[Mouvedia]

I really don't understand why it was necessary to remove these rules and then return them to the organization as a plugin

I am not representing the organization in any way. I am just giving my own opinion: if the usage of a plugin becomes ubiquitous it might be worth repatriating it. Ill eventually create the table I was talking about in this comment.

[hudochenkov]

I really don't understand why it was necessary to remove these rules and then return them to the organization as a plugin 🤭

Wouldn't it have been easier not to remove them? 👀

@firefoxic This is exactly what @ybiquitous said before: “If we provided an official stylistic plugin, it would not be much different from maintaining the built-in rules as before.”

I agree with @ybiquitous: this plugin should not be part of Stylelint organization. If we thought that they need to be part of Stylelint organization, these rules would be still in Stylelint core.

There's one advantage of having it under stylelint/: you two could collaborate on the maintenance efforts if both plugins compete for the same purpose.

@Mouvedia nothing keeps two people to collaborabe in their own repository. No need to move Stylelint organization for that.

If @elirasza wants to stop maintaining the plugin, we may need to find a new maintainer like we did with postcss-css-in-js.

@ota-meshi We've never found a maintainer for postcss-css-in-js.

---

@elirasza @firefoxic I suggest to pick one of your plugins. Deprecate the other one. And together you could work on a single plugin. It would help you both, since you would need to do less work each. It would help community, as they would not need to choose between two plugins doing the same thing.