EditorConfig vs. Eslint vs. Prettier: Is it worthwhile to use them all?

I am trying to set up some tools to help maintain consistency in a codebase used by multiple developers. Is it necessary to use EditorConfig, ESlint and Prettier all together? As far as I understand, EditorConfig is used to set coding styles/rules, ESlint is used to ensure code is formatted consistently by throwing warnings if code does not follow rules, and prettier is used to automatically format code based on the rules. However, I believe you can customize rules in prettier, which in turns does the job of EditorConfig. Is this true? What is the best combination of tools to use to maintain consistent code?

In my experience, the best combination is all 3, and here's why:

EditorConfig: This helps your editor produce code that looks like your style guide as you go. While this isn't strictly necessary in order to achieve your goals, it's nice if you're always looking at code that follows the same coding styles. Otherwise if you don't have EditorConfig, as you're typing your editor will auto-format differently to the rest of the code base, which is confusing. Of course if you've set up prettier it'll fix it before it goes into your code base, but still, why would you want to look at it in one format while you're writing it and then have it switch when you go to commit? Might as well be consistent.

Prettier: Automatically formats your code. I like to set it up to do this when I stage my files for a commit, so that it's physically impossible for me to commit code that doesn't match my style guide.

ESLint: So why would you want a linter too? Because ESLint does more than just style. It picks up when you declare variables you don't use, or reference things that aren't defined, amongst a few other niceties. So while its role diminishes somewhat compared to the days before prettier, it's still useful to have in a project to catch the other errors.

Hope that helps!

Prettier

It removes all original styling and ensures that all outputted code conforms to a consistent style.

• It changes your code after writing your code.
• For example
  • on save with VSCode editor
  • with CLI like prettier --write .

Editorconfig

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

• It applies your rules before writing code
  • For example
    • When you press TAB, it leaves 4 spaces.

ESLint

ESLint statically analyzes your code to quickly find problems.

• ESLint finds problems in your code

To summarize:

• EditorConfig changes your editor settings.
• Prettier updates your code with your rules to reshape your code.

Finally:

• They have some common features in order to do the same things.
• I also agree with @KevinBrownTech to use 3 of them. Especially if you are working with a team.

Useful sources for who want to dive into:

• Feross Aboukhadijeh: Write Perfect Code With Standard And ESLint - JSConf.Asia 2018
• https://standardjs.com/

Also look at React framework's repo:

While I think it's clear that you need both eslint and prettier I actually think that you can get rid of editorconfig at least in some cases.

If you have your editor setup to automatically format your code using prettier then the only difference between prettier and editorconfig is the rules they use.

For example prettier might not remove trailing white space in some cases or it might have a default rule that is impossible to change.

However if you're ok with the prettier rules and your editor supports autoformat using prettier than I guess you can remove editorconfig.

This is a clearer answer from @kevinBrownTech.

> when you use for example the VSCode extension for prettier, it > formats on save. It won't format while you're typing to match your prettier styles. For example, I use tabs, and without Editor > Config, VSCode defaults to spaces until I save, then it'll run > Prettier

In conclusion, the .editorconfig role is to configure your editor so that the code you write is already formatted while Prettier will format your already written code, EsLint makes sure your code conforms to best practices or rules set within it's config.

I would use .editorconfig and ESLINT but avoid prettier - it's an opinionated code formatter and ensures consistency (which is a good thing) but it might go a bit too far.

Code-Style is opinionated and I strongly believe the best code-style is the style your team or organization agrees on - just discuss it and give everyone a chance to be heard and you will have more happy developers. The problem with Prettier is that they bluntly force THEIR opinion on you and give you no options to turn off the things that bother you. They are lacking configuration-options and they will probably never add them, since it's against their options philosophy of wanting to "stop all the ongoing debates over styles", which can only happen if every single developer accepts the same styling. I personally don't think that this is even desirable. First people are different and want to use different styling. Second People use different languages and Prettiers opinion clearly works better on some (like Java/JavaScript) than others (like HTML). Prettier could have solved all that with configurations and really be the one formatter everyone uses, but sadly (imo) instead of wanting to be the one formatter they want to be the one CODE STYLE. Not saying it's all bad, but their vision might not be for you - if you want the freedom to decide yourself how YOUR code looks better use another formatter.

PROBLEMS WITH PRETTIER:

Problem: print-width

Prettier uses a "print-width" setting (see Prettier options) to make sure lines end somewhere around the same character. This will for example break up lines that are too long, which is something all code-formatters do. Prettier does it his own opinionated way. A short HTML example of a div with 2 Angular directives, a few classes and some accessibility attributes:

<div *ngIf="ability?.length > 0 && ! loading" tabindex="0" myCustomDirective class="col-lg responsive-input-wrapper d-flex align-items-center" role="navigation" aria-label="Primary">

Now prettier would format it to this:

<div
  ngIf="ability?.length > 0 && ! loading"
  tabindex="0"
  myCustomDirective
  class="col-lg responsive-input-wrapper d-flex align-items-center"
  role="navigation"
  aria-label="Primary"
>

That certainly for his own is more readable. Some points though: When editing HTML you are rarely interested in all attributes. You usually will have a specific goal. Let's say you are styling something, than you will scan the code for "class" attributes and are more interested in the overall structure. The thing with prettier is: With all that line breaks you can fit maybe like 4 elements on your screen! While for those 4 elements every attribute for itself is highly readable this comes at a great cost to the readability of the overall structure. You will have to scroll a lot if you are interested in more than your 4 elements and that can be incredibly frustrating. For me HTML (especially with their ridiculous recommended line length of just 80) formatted with prettier is insanely hard to read and comprehend.

Most other formatters would do it differently (or let you choose) and split the line only when necessary, so you have just 2 lines instead of 8. Everything would still be visible without horizontal scrolling (which I think we all agree is terrible and has to avoided). Even better: a sensible developer could think about what's important to read in what context and could come up with a solution like this:

1. Angular attributes and directives go into the first line
2. Classes and Styling goes in the second line
3. Accessibility goes into the third line

This could like so:

<div *ngIf="ability?.length > 0 && ! loading"  myCustomDirective
     class="col-lg responsive-input-wrapper d-flex align-items-center"
     tabindex="0" role="navigation" aria-label="Primary">

This could be a good middle ground. You have only 3 lines and can still see much of the overall structure, but have great readability of the attributes as well (especially with the split between Angular / Style / ARIA).

Problem: removing mindfully set linebreaks

Another thing Prettier does is combining your lines, removing linebreaks you intentionally added for increased readability - let's say you always want Accessibility tags in a second line -> impossible to do with Prettier! If both lines combined fit within the "print-width" it will collapse them into a single line, no matter what you want!

Problem: format jumping

It's easy to lose track where you have been in the code. You are writing three lines of code, hit your auto-format hotkey and suddenly are completely lost, because the file got completely re-formatted. This is somewhat true for all formatters, but no other is THAT intrusive and adds like 15 newlines for three lines of code!

When to use it

Only use prettier if you have no better option. Let's say it is a very heterogeneous environment, like an open source project - people all over the world with different environments and IDEs working on the same thing. It's hard to explain and enforce more sensible code-styling in such environments. Prettier is a good solution for those cases, because you can't rely on IDE settings in this case and .editorconfig is a bit limited.

But for your typical work project with like 5 developers using the same operating system and tooling there are much better and more flexible choices, especially for formatting HTML. Editorconfig is a good starting point. Even better: if you all use the same tooling you can just check in your project formatter and everyone's IDE will just use that. Some IDEs (e.g. IntelliJ/Webstorm) can import/export your formatter settings to other IDE formats as well.