Why You Should Use ESLint, Prettier & EditorConfig

This article is the first in a series on how to enhance your development environment using ESLint, Prettier, and EditorConfig. If you already know ESLint, Prettier, and EditorConfig and want to know how to benefit from their combined use, don’t worry! You will learn how to configure ESLint, Prettier, and EditorConfig to work well together in the next article in this series on collision-free Settings.

background

In one of our typescript-React projects, we decided to use both ESLint and Prettier to detect and format code. We struggled for days with the conflict between ESLint and Prettier format rules. Our code at the time looked something like this:

After some exploration, we managed to get ESLint and Prettier to co-exist and work together. Based on this, we even added EditorConfig to the composition. In response, I wrote some articles on the subject to share my new findings. It took us a while to solve the formatting problem, but we didn’t give up on the idea of ESLint, Prettier, and EditorConfig working together. The reason is simple: although the three have similar purposes, they are still specialized.

Introduction to ESLint, Prettier, and EditorConfig

What are they for

All three tools have similar goals:

  • Maintain consistency between the code itself and between team members.
  • Detect problematic code patterns that can lead to potential bugs.

ESLint is by far the most popular JavaScript code detection tool. It statically analyzes your code to help you detect formatting problems and find inconsistencies in your code.

Prettier formats code much like ESLint, but it doesn’t check the quality of your code. It serves only as a code formatting tool. For the JavaScript it supports natively, it does a pretty good job. However, it also supports JSX, Flow, TypeScript, HTML, JSON, CSS, and many other languages.

EditorConfig does not detect or format your code. It simply defines a standard code style guide among all ides and editors used within the developer team. For example, if a team mainly uses Sublime Text and VSCode, EditorConfig enables them to define common indentation patterns (Spaces or tabs) within a single file.

Custom rules

Your custom rules for ESLint, Prettier, and EditorConfig determine your code review and formatting experience.

ESLint configuration is located in.eslintrc.* files (such as.eslintrc.json or.eslint.yaml, etc.), which can be used to define your own set of rules, or for different frameworks (React, Vue, TypeScript) uses plug-ins. We will use this configuration file later as well.

Unlike ESLint, where a configuration file is required, Prettier doesn’t need one at all, so the development team can focus on more important things. However, it also supports custom rule items in the.prettierrc.* file.

Finally, the.EditorConfig file actually overrides the configuration of any IDE or editor. This allows you to create a common multi-editor development environment for team members.

Automatic repair capability

ESLint and Prettier both provide an auto-fix function that changes your code whenever they find a fixable error. This nifty feature can be integrated into your IDE or editor so you can correct and format files when you save them or paste code.

Wait a moment! Why do all three tools work together?

That’s a good question! ESLint already formatting code automatically, why Prettier? Assuming we did, why bother EditorConfig when Prettier already does not need formatting code from an editor

To answer the first soul check, you should remember that code checkers (Linters) essentially have two types of rules:

  • Formatting rules: Prevent code style inconsistencies & avoid ugly code styles (e.g.max-len.no-mixed-spaces-and-tabs.keyword-spacing.comma-styleEtc.)
  • Code quality rules: Prevents useless and error code (e.g.no-unused-vars.no-extra-bind.no-implicit-globals.prefer-promise-reject-errorsEtc.)

ESLint can apply both types of rules and, if possible, fix code automatically. Prettier, on the other hand, only checks for formatting errors in code, but is more professional than ESLint.

For example

To illustrate this, we built a simple JS file main.js and will use the CLI to run ESLint and Prettier to demonstrate.

function printUser(firstName, lastName, number, street, code, city, country) {
    console.log(`${firstName} ${lastName} lives at ${number}.${street}.${code} in ${city}.${country}`);
}
printUser('John'.'Doe'.48.'998 Primrose Lane'.53718.'Madison'.'United States of America');
Copy the code

Note that we used TAB indentation of 4 characters.

We added ESLint and Prettier as development dependencies to our project so that we could compare the two tools in the same file.

npm install eslint prettier --save-dev
Copy the code

We also added a simple.eslintrc.json configuration file to add ESLint recommendations, which also enabled ES6 expressions (such as backquotes) and node variables (for console.log).

In this configuration, we added some custom rules:

  • Indentation of two Spaces
  • Each line of code should not exceed 80 characters
{
  "extends": ["eslint:recommended"]."env": {
    "es6": true."node": true
  },
  "rules": {
    "max-len": ["error", {"code": 80}]."indent": ["error", 2]}}Copy the code

Now let’s run ESLint on a terminal:

npx eslint main.js
Copy the code

ESLint disallows the use of console statements and detects Tab indentation. It expects space indentation, and two long lines of more than 80 characters are detected.

Now let’s use the fix option to see what it can do:

npx eslint main.js --fix
Copy the code

ESLint corrects the indentation problem, but not the problem caused by the max-len rule.

Prettier now run Prettier, whose default configuration is 2 space indentation and a maximum of 80 characters per line, just as ESLint does.

npx prettier main.js --write
Copy the code

Look again at the contents of the main.js file:

function printUser(firstName, lastName, number, street, code, city, country) {
  console.log(
    `${firstName} ${lastName} lives at ${number}.${street}.${code} in ${city}.${country}`
  );
}

printUser(
  'John'.'Doe'.48.'998 Primrose Lane'.53718.'Madison'.'United States of America'
);
Copy the code

Prettier reformatted our code without us specifying any configuration, fixing a problem caused by the Max-Len rule that ESLint couldn’t fix. But Prettier doesn’t warn us about the console.log statement that belongs to code quality rules. Therefore, in order to get the best inspection experience for code quality and formatting, you really should use both tools together.

As for the second-soul question about EditorConfig and Prettier, the answer is simple: neither can replace the other. Where EditorConfig configures your editor so that the code you write is already well-formed, Prettier formats the code you write. EditorConfig is available for more languages and projects than Prettier.

EditorConfig also prevents Prettier from saving code because your editor already formats it according to EditorConfig rules. The tricky part, though, is making sure Prettier and EditorConfig have the same rules and don’t have to be reconfigured in two separate files.

conclusion

The combination of these three tools can really improve your development experience, the question is how do we configure them to work together.

For the record, I’ve seen a project where the team abandoned ESLint in favor of Prettier. If you don’t want to choose all three tools for your project, just one of them is up to you. However, remember that Prettier doesn’t provide any code inspection, it just formats your code and ignores syntax. Therefore, it is highly recommended that ESLint be used before Prettier is considered.

That said, format conflicts may occur if you want to use both programs at the same time. ESLint might think your code is formatted differently from Prettier. In addition, using EditorConfig and Prettier together lets you write redundant configuration. So how do you configure all these tools so that they work well together? The answer is in the next article on conflict-free Settings ESLint, Prettier, and EditorConfig.