stylelint
stylelint copied to clipboard
stylelint
Become an ESLint plugin
ESLint has an exciting proposal (https://github.com/eslint/rfcs/pull/99) for Stylelint to become an ESLint plugin.
We're a small team of volunteers working on Stylelint. A couple of us share the sentiment that it would free us up to add more rules to help people rather than spend our time on file-finding, config, caching etc. It'd also let us tap into ESLint's pool of integrations, e.g. its VS Code extension.
This issue is to draw people's attention to the RFC. Please share your thoughts here on whether you think this is a good idea or not. If you've thoughts about the particulars of the RFC itself (especially the technical nitty-gritty), please then comment there instead.
I'm not sure this is a good or bad idea. There is a positives, like maintenance of the core of the linter become non-issue, as it would be on ESLint.
On the other side we would need to write and maintain completely new thing — plugin for ESLint, to bridge the gap between ESLint core and Stylelint rules.
Change all rules to work with ESLint. Whatever result of that RFC would be, rules would have to be changed for new core.
Lose all of Stylelint plugins. Even if there would be a way to have plugins for plugins (see my questions in RFC). Stylelint plugins authors would need to create ESLint version of their plugin.
User would have to navigate in all of this, change their configurations, editor settings, packages, CI.
FYI, the ESLint team has published an official CSS plugin: https://github.com/eslint/css
I'm curious about what the ESLint team will support for the Stylelint community. For example, add more rules, custom syntax support, third-party plugin support, etc. (@ota-meshi may have some info about this since he's a member of ESLint)
@ybiquitous I'm also curious as these are interesting times.
It feels like the linting landscape has fragmented recently and seems to be becoming:
- ESLint: a linter for many languages
- Prettier: a formatter for many languages
- Biome: an everything for many languages
- ZeroVoid (Oxc): an everything for JavaScript
Fragmentation is neither good nor bad; choice brings innovation at the cost of duplicated effort.
Both Biome and ESLint reference Stylelint's rules as prior art, with the former having ported over nearly all of our recommended rules. It's heartening to see that people will benefit from our efforts in creating a cohesive set of rules, regardless of the tool they use. Just as we greatly benefited from borrowing ideas from the CSSLint and ESLint authors.
With each tool's pros and cons, predicting how the dust will settle is difficult. Until it does, I plan to focus on Stylelint but watch the Biome and ESLint repos to pass along any lessons we may have learnt so that the CSS community benefits.
Our intention to add more rules to help users write modern CSS still feels right (as these efforts are transferrable to other tools). It probably makes sense if we delay making potentially disruptive changes (e.g. flat config) as our users likely appreciate the stability of Stylelint. However, we may all have differing opinions on this. It also seems unlikely that ESLint and Biome will support CSS language extensions like SCSS, so we should continue to support those communities.
As an aside, Stylelint turns 10 in a couple of weeks 🎉 . Thank you all past, present and future contributors. What a journey!
FYI, ESLint announced the CSS support a few days ago: https://eslint.org/blog/2025/02/eslint-css-support/
I'm unsure about the @eslint/css direction, but I find it worthwhile for many people writing CSS to unify these two tools.
However, there seem to be some challenges to achieve it:
- Very many assets in the Stylelint community, such as plugins, syntaxes, etc.
- Differences between ASTs, i.e., PostCSS and CSSTree
- Stylelint is based on PostCSS and partially uses CSSTree for some built-in rules
- ESLint CSS Plugin is based on CSSTree and doesn't support PostCSS's AST
- Note: This reminds me of https://github.com/stylelint/css-parser/issues/2