EditorConfig vs. ESLint vs. Prettier: Is it worthwhile to use them all? [closed]

Question

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?

Maurreen

Answer 1

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.

Apivorous

Thanks @Apivorous for your helpful response! For prettier, do you know if its possible to prevent prettier from breaking up a function that is over the max characters based on every commas (e.g. for timeouts or nested functions over the characters limit, prettier will break it down to 3 separate lines) – Maurreen

You will have to increase the printWidth: prettier.io/docs/en/options.html#print-width – Laliberte

I didn't get it why I should use EditorConfig and Prettier at the same time. It's also possible to format your code in your IDE with Prettier. You can integrate EditorConfig in your CI toolchain as well so there is no need for Prettier. Can you please explain in more detail? – Conflation

I second @Conflation 's comment. Did not get it why not just use Prettier. Could use a more clear explanation. – Italianism

@laprof, 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. As I explained in the answer, it's not critical but it's nice to have consistency. You could absolutely do without Editor Config, but I prefer to have it for this reason. – Apivorous

So setting up auto save on every change, it would even reduce the reliance on editorconfig... right? – Devonadevondra

EditorConfig configures code style rules in your editor. Prettier parses your file and fixes issues. The reason why you should use EditorConfig is because O(1) is better than O(N). – Benedictbenedicta

Answer 2

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 the Visual Studio Code editor
  • with a 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 four 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 three 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
• JavaScript Standard Style

Also look at the React framework's repository:

Discordance

What do you mean that EditorConfig applies before writing the code? I'm trying to understand how to enforce double quotes and that is something that needs to be corrected after typing apostrophes (i.e. single quotes). What do I miss? – Oujda

Answer 3

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 then I guess you can remove EditorConfig.

Tuscany

Answer 4

I would use EditorConfig (file ~/.editorconfig) and ESLint, but avoid Prettier.

TLDR

Stay away from prettier for HTML or other markup languages. It's a nightmare to read and maintain, and you loose so much readability of the overall structure just for the sake of increased readability of attributes that are irrelevant 99% of the time (imo). Also Prettier forces you to comply to their opinion instead of being able to use the format your team agrees on.

FULL EXPLANATION

Prettier is 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 Prettier's 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. I am 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: removing mindfully set linebreaks

For me, the most annoying 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 reformatted. This is somewhat true for all formatters, but no other is that intrusive and adds like 15 newlines for three lines of code (see next point)!

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 div with two 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 its 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, and then you will scan the code for "class" attributes and are more interested in the overall structure.

The thing with Prettier is: With all those line breaks you can fit maybe like four elements on your screen! While for those four 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 four 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 two lines instead of eight. 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 where relating stuff is kept on a consistent line (e.g., Angular attributes and directives always on the first line, etc.)

This could look 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 seems a good middle ground. You have only three lines and can still see much of the overall structure, but you have great readability of the attributes as well (especially with the split between Angular / Style / ARIA).

That's impossible with Prettier though, since it will collapse your intentional linebreaks (see problem 1) or write every single attribute on a new line, even when all three lines would fit within the print-width (Problem 3)

WHEN DOES IT MAKE SENSE TO USE PRETTIER

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 five developers using similar IDEs and tooling, there are simply 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 IDEA and WebStorm) can import/export your formatter settings to other IDE formats as well.

Aforetime

The bottom line can be moved as TLDR to top. Readers might not reach till end. – Stotinka

@Stotinka thanks for the tip, i updated my answer to do this. – Aforetime

this is heavily opinionated answer affected by lack of a knowledge how prettier works. Most of your issues are solved by prettier's settings. Bear in mind the whole point of prettier is force developers to keep the same the format same across whole project but its up to developers to setup the prettier correctly for their needs. – Azriel

I know prettier very well and have used it in some projects. Maybe you can elaborate? What options exist that solve the 2 main issues described? ("Removing mindfully set line breaks, even when they fit the print-width" and the problem that you can't have multiple attributes per line once the print-width was overstepped - it always forces you into a line-per-attribute format) – Aforetime

Answer 5

This is a clearer response from KevinBrownTech.

when you use, for example, the Visual Studio Code 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 EditorConfig Visual Studio Code defaults to spaces until I save, and 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, and ESLint makes sure your code conforms to best practices or rules set within its config.

Mera