Linting and formatting CSS

[survivejs]

Linting and formatting CSS

[gavinorland]

Looks good but I think I might be able to add something. Please leave it open and I'll get back to you ASAP.

[sapegin]

How many rules does Prettier implement over CSS? Some are exposed via options, I guess there are others.

It doesn‘t implement any rules, it formats code, so you’ll need to remove any code style rules from Stylelint config. Same as with ESLint.

Will Prettier support plugins, as Stylelint does (such as Order)? This strikes me as a very useful plugin which makes Stylelint worth using right away.

I’m 99.9% sure it won’t. The whole point of Prettier is no config and no arguments on code style in teams ;-) But you can continue use Stylelint with this plugin.

Can Stylelint --fix all the rules that Stylefmt used to be able to do (thus rendering the latter definitely redundant)?

That’s why we removed Stylefmt from the book ;-)

Are there things that Prettier fixes in terms of formatting that Stylelint does not, thus making it worth using?

Stylelint doesn’t reformat code, it just enforces some code style rules. I think I’m answering this question here.

Should we all these to the book? ;-)

[sapegin]

Bottom line: what's the best workflow with these tools to take maximum advantage of linting and fixing, without redundancy?

The one we explain in the book ;-)

[gavinorland]

What I meant by Prettier implementing "rules" was its internal rules for formatting which might match ESLint's. Sorry if I didn't make that clear.

I agree it looks very unlikely that Prettier will implement plugins - I appreciate it is deliberately minimal in config.

That’s why we removed Stylefmt from the book ;-)

I'll take that as a "Yes" that Stylelint can now fix all the rules that Stylefmt could - thanks!

Stylelint doesn’t reformat code

Couldn't we say Stylelint does some reformatting in the sense of using --fix to change spacing etc.?

Thanks - I will have another look at your article, although I think it relates only to JS. I was just wondering if there is formatting of CSS that Prettier performs that stylelint --fix cannot.

Yes, as you say in the book, perhaps ESLint and Prettier are both worth running. Feel free to close this if you think you already have these points sufficiently covered.

[sapegin]

What I meant by Prettier implementing "rules" was its internal rules for formatting which might match ESLint's. Sorry if I didn't make that clear.

I don’t think such comparison makes much sense because Prettier completely reformats the code from AST and only very basic rules like quotes or semicolons may match ESLint.

Couldn't we say Stylelint does some reformatting in the sense of using --fix to change spacing etc.?

We have some terminology issues here ;-) ESLint / Stylelint do change formatting a bit: add or remove whitespace, change type of quotes, etc. But they don’t reprint code from AST like Prettier does. So ESLint / Stylelint try to fix already formatted code and Prettier completely (not 100% but very close) ignores original code formatting. I don’t think we should use the same word to describe both processes. @bebraw what do you think? ;-)

Thanks - I will have another look at your article, although I think it relates only to JS. I was just wondering if there is formatting of CSS that Prettier performs that stylelint --fix cannot.

It describes the difference between two different processes: Stylelint can‘t do the thing we don’t know how to call that Prettier does ;-)

Yes, as you say in the book, perhaps ESLint and Prettier are both worth running. Feel free to close this if you think you already have these points sufficiently covered.

I think it can be improved, so let’s keep it open 🍕

[gavinorland]

I would certainly say that ESLint and Stylelint format code when they fix those kinds of rules. By contrast, Prettier reprints all of the code, as you say, also formatting. It's just more of a "nuclear option"!

Just to be perfectly clear, is there anything that Prettier can format that stylelint --fix cannot?

I'll get back to this tomorrow and mention if there is anything else I'm still not clear on. Thanks again :)

[gavinorland]

A new article on this topic with an interesting post by the main developer of stylelint. Seems to me the main thing Prettier fixes (reprints) that Stylelint doesn't is line length. Main benefit of using stylelint in tandem with Prettier seems to be ability to use plugins like Order, as I mentioned (though it lints many other things too). Stylelint cannot yet fix all the rules that stylefmt can (see for example declaration-colon-space-after), but they're adding them all the time. :)

[sapegin]

Probably we need to add a short section on liters v. formatters to clarify why you need to use both.

[sapegin]

This should make it more clear: #62

[bebraw]

@gavinorland What do you think? Time to close?

[gavinorland]

Right, I was just reviewing what exactly are the differences between the tools again. Of course, Prettier actually reformats, but I wanted to check on what it does that ESLint cannot. If you wanted to be a bit more explicit for the curious reader (like me!) maybe this would be of use:

A common misconception is that if you use a code formatter like Prettier then you don’t need a linter anymore. However, Prettier will not touch any code quality issues, such as unused variables or implicit globals. And while both ESLint and Prettier can auto-fix semi-colon, indent, quote, comma dangling and spacing preferences, Prettier can operate on more file types (including JSON and CSS) and, as it reprints, it can also for example auto-fix line lengths where possible and remove unnecessary space between code blocks. Therefore at present it's worth using both of these tools together.

Up to you guys!

[sapegin]

@gavinorland Take a look at #63, is it better now?