New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document stylistic plugin in migration guide #6753
Comments
@elirasza Great! We appreciate your work! 👏🏼 Could you add your stylistic plugins to our awesome list if you don't mind? |
Thanks for the quick reply. I have sent a PR : stylelint/awesome-stylelint#52 ! |
The awesome list now includes the I'll make this issue open for a while so that people can easily find such a plugin that includes deprecated stylistic rules. |
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). |
@kerryj89 Nice catch. I agree we would recommend this plugin in the migration guide. 👍🏼 |
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. |
Good job!
Thanks to this plugin for helping us get back to using stylistic-rules |
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 ? |
Actually stylelint becomes even more useless without stylstic-rules, so we also hope that stylstic-rules will be an official plugin. |
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. |
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 |
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 |
While writing, I forgot why I came :) |
It should be recommended, but it seems difficult actually. To be honest, I guess it's not required. |
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. |
Someone can provide why |
You should focus on what your write, not how you write |
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. |
@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 |
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. |
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. |
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. |
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. |
I was proposing that you continue maintaining the plugin under the |
Would anyone be passionate about actively maintaining the repository (e.g., /cc @stylelint/owners |
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. |
I'm not sure if this is appropriate, but I don't want to stop maintaining my plugin 👀 |
All we are discussing will be really relevant in the next major release cycle. |
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? 👀 |
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. |
@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.
@Mouvedia nothing keeps two people to collaborabe in their own repository. No need to move Stylelint organization for that.
@ota-meshi We've never found a maintainer for @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. |
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 !
The text was updated successfully, but these errors were encountered: