#Stylelint deprecated all stylistic rules and #ESLint is also kinda moving in that direction.
Maybe it’s finally time to take a look at #Prettier? 🤔
But I definitely have to configure it so code stays readable and doesn’t become this mess of seemingly random line breaks.
Ever looked at what Prettier does to JS template literals? It’s certainly something 😬
New releases by me:
- stylelint-a11y 1.2.7 https://github.com/ronilaukkarinen/stylelint-a11y/releases/tag/1.2.7
- gulp-stylelint 14.1.1 https://github.com/ronilaukkarinen/gulp-stylelint/releases/tag/14.1.1
- devpackages 2.5.3 https://github.com/digitoimistodude/devpackages/releases/tag/2.5.3
- air-light 9.2.9 https://github.com/digitoimistodude/air-light/releases/tag/9.2.9
#OpenSource #CSS #Stylelint #WebDev #WordPress #WordPressStarterThemes #wpfi #Gulp
#opensource #css #stylelint #webdev #wordpress #wordpressstarterthemes #wpfi #gulp
"As of Stylelint v15 all style-related rules have been deprecated."
Even this sentence doesn't make any sense. Stylelint is all about styles.
I actually liked having formatting and pretty printing all in the stylelint itself without the need of other plugins.
Modularization goes too far sometimes. Just look at all the postcss plugins... #CSS #Stylelint #WebDev #Prettier
#css #stylelint #webdev #prettier
Remembered the time when I contributed to #OpenSource and did two #stylelint PRs that are already merged:
1. https://github.com/stylelint/stylelint/pull/6589 — makes the messages a bit more configurable for a number of rules.
2. https://github.com/stylelint/vscode-stylelint/pull/442 — exposes one of the stylelint settings in its vscode extension.
Need to do this more.
I spent the entire morning overhauling my #stylelint configuration. Going through the list of rules and setting up *everything* is kinda fun 😁
Have to test this with a real project before release.
There should be versions of `eslint-disable`, `stylelint-disable` (-line etc) that would instead of removing the errors & warnings, reduce the severity: removing the warnings, and making errors into warnings.
This way it would be possible to mark something be safe to pass the CI, but keep the visible warning.
Otherwise, we basically need to make a separate rule that targets the disabling comment for a specific rule and gives a warning for it, which is a bit meta.
Has anyone experimented with rome as a replacement for #Prettier and #ESLint / #stylelint? They've just released version 10 that is rewritten in #rustlang, for crazy perf gains. I'm curious what the migration would be like. One downside is that it sounds like they don't support any kind of plugins, so far.
RT @sebmck: https://twitter.com/sebmck/status/1589987087780302848
Announcement: https://rome.tools/blog/2022/11/08/rome-10.html
#prettier #eslint #stylelint #rustlang #javascript