Integrating and Enforcing Prettier & ESLint

[utterances-bot]

Integrating and Enforcing Prettier & ESLint

How to resolve the conflict between Prettier and ESLint and use ESLint to enforce Prettier in your codebase.

https://silvenon.com/blog/integrating-and-enforcing-prettier-and-eslint/

[Zamiell]

Hey Matija,

This is a fantastic blog, and the conclusion of "just use 1 tool via eslint-plugin-prettier" was very helpful to me when I started setting up my linting framework back in 2019.

However, a friend pointed out to me recently that using eslint-plugin-prettier is not recommended by Prettier itself. I think Prettier's point of avoiding pointless "red squiggly lines in your editor" has some merit, so I am considering switching. (Another point that might have merit is the performance increase, but I haven't done any benchmarks myself.)

The other major point that my friend brought up has to do with projects that have other files than JavaScript/TypeScript. In the same way that you want your TypeScript files failing in CI when they are not formatted correctly, you would also want JSON/YAML/HTML files failing too. And ESLint can't lint those files - only Prettier can. So as long as a project has JSON/YAML/HTML/whatever files, even though we are trying to avoid installing/using two different tools, we end up using Prettier anyway. I have to admit that this is a pretty serious drawback, since lots of projects are going to have those kinds of files.

What do you think about this? And has your standard linting setup changed at all in the two years since you have written this blog?

[silvenon]

Hi Zamiell,

This is really interesting feedback, thank you! To answer your last question, I'm still using this setup, which is pretty unexpected even to me in the world where we change frameworks every couple of months 😄

I didn't know that Prettier discourages using eslint-plugin-prettier! I carefully read the documentation page you linked to, and I think their explanation is a little unfair because it doesn't point out the benefits of using eslint-plugin-prettier (talking about JavaScript and TypeScript now, I'll get to the rest later):

• In new projects you don't have to set up your editor to also prettify on save, just fix ESLint, which you only have to set up once because it can detect an ESLint configuration. It would be nice if VS Code extension for Prettier could do the same, but apparently it can't currently.

• While I agree that underlining formatting "mistakes" is a little noisy, knowing what is going to change when I save the file makes it much less disorienting, so I guess it's a matter of preference, and setup.

• .eslintignore also covers Prettier. If I want some files linted but not prettified (a very rare need), I can use .prettierignore.

• I don't agree with the last drawback they mention, "one layer of indirection where things may break", to me using eslint-plugin-prettier makes Prettier one less tool to worry about. I personally don't see how using eslint-prettier makes things any better because it couples the tools on the CLI level, instead I would just run commands separately if my goal was to separate them. A few days ago my colleague was tangled up in a problem with ESLint and Prettier which wouldn't happen if he configured ESLint to use the plugin.

• There are probably a few more things I wanted to say about this, but I forgot as it's a big topic for me. 😃

I can imagine that there is some impact on speed, though, I haven't measured it either. I would like to compare it, though.

Now let's talk about other file types that Prettier can format. First of all, you said something about avoiding/installing two different tools, but with the setup I recommend in my post (or any other for that matter) you'd be doing both, you're always both installing and using Prettier, it just varies how you're using it. For other file types you can have a separate setup, for example in lint-staged you might have eslint --fix set up for *.{js,ts}?(x) files, stylelint --fix or whatever it is for *.css, and for other files you might set up prettier --write.

I understand why this makes your friend ask why did would we join ESLint and Prettier at all if we're running Prettier separately for other file types, but the answer is hopefully simple — most benefits I mentioned previously still stand regardless of this, you also likely have less code written in other languages, so some of the problems that joining ESLint and Prettier alleviates might not be significant problems for them. Also, maybe you don't want Prettier to run on every file, only on some, perhaps in some cases you want to control the formatting.

In summary you should be able to combine both approaches just fine. What do you think about that?