Recently i thought about dropping Prettier from my dev-dependencies in order to reduce a tool in my chain. I thought of using ESLint instead.
Before just jumping into doing so i did some research and finally decided to leave things as they are.
Motivation
I hate to have to many tools floating around in my projects. I mean in general. So i’m always looking into minimizing dependencies as much as i can without loosing anything valuable.
Seeing that ESLint is practically capable of reformatting the code it analyzes; and it having an explicit ruleset geared towards code style i started thinking of why i use Prettier at all.
Swapping out Prettier?
After the initial thought i started doing some research as i tend to mistrust my desires when it comes to things like this.
I looked into the ESLint ruleset realizing it actually seems to have all the rules one might need to replicate Prettier’s ruleset. That ruleset has a dedicated section in the Rules Reference.
Then i started laying out a strategy in my head of how to approach phasing out Prettier in my time tracker project. Then it hit me:
- Just trying to replicate Prettier’s output is hard. Not that i’d want to replicate it 100%, but finding all edge cases and configuring them properly even with a solid style guide is hard and takes a lot of time.
- On top of that this would only cover TypeScript/JavaScript and nothing else. This is highly undesirable as i don’t want to start that process with any other language i use or might use in the future each time too…
This also made me understand the common notion around separating concerns in the form of having linters and formatters. Technically linters (taking the word lint literally) could also format and it’s fine to use them for that purpose; linters are nowadays generally understood and primarily designed to find potential bugs or bad practices in your code. Having that in mind it’s odd to think, a linter also format the code as well.
So, no, i do not swap out Prettier, i keep it and i learned to appreciate its existence even more than i did before!
Bare in mind, this is a convenience decision, favoring simplifying the overhead of properly configuring the formatting and properly separating the concerns.
An analogy (and etymology)
Think of knitting a sweater. The formatting would basically be the pattern you knit your sweater in. Is it just one color (think minified code which is just one big blob if characters) or does it have a nice checkered pattern of blue and yellow (think prettified code)?
Now, wearing your sweater after having finished knitting it will result in lint on it to appear over time. If you care about your sweater and its appearance you might start removing those with a lint brush.
The terms linter and linting are derived from that original term and the associated process of removing it.
Interesting side-note
While researching i found out Stylelint deprecated all format related rules with version 15. They themselves state, that this is in light of tools like Prettier existing and that is a consequent move.
The reasons they give are a good read to understand the common sense around formatters and linter.
Further thoughts on formatters vs. linters
There is one specific set of rules i fancy a lot: The rules that are responsible for sorting definitions like variables, object properties, class properties, css properties, import and export etc. Preferably i like to simply have them sorted by alphabet as this is most deterministic and simple to reason about.
Within what reasoning do these fall? There’s no severe potential risk regarding bugs when things are not sorted; rather it might introduce bugs when dependencies are potentially depending on one another. It’s not really a formatting related issue either, is it? This confuses me a bit, honestly.