background

In my project, I ran into a problem where typescript/ ESLint and Prettier collide, resulting in an ugly red wavy line wherever formatting was done, as shown in the video below.

In my React project, WHERE ESLint and Prettier were used for formatting, it was clear that esLint and Prettier’s formatting rules for indentation were in conflict. But why is there a conflict, and how should the configuration be correct? EditorConfig+Prettier+ESLint Many people know that EditorConfig+Prettier+ESLint allows team members to check, restrict, beautify code and unify coding style during code development, but they don’t know why. Then I saw two articles on the Internet, which were very good, so I translated them for everyone to study together.

This article will try to explain the reasoning behind esLint and prettier so that it can be used in the future when there are problems with esLint and Prettier.

EditorConfig,prettier,eslint

In a nutshell: ESLint would be our code quality checker, Prettier would be our code formatting tool, and EditorConfig would provide the right editor configuration for everyone.

JavaScript as weak type of dynamic language, because of lack of compilation phase, some of the errors can be found in the compilation process, can only wait until run time to find, the debugging and find hidden problems in advance to us with some difficulty, while the Lint tool of js increased the compilation process, before the code deployment operation for static analysis, Find errors and irregularities, and format the code with –fix.

Now that TypeScript is available and can catch a lot of code problems at compile time, what else does Lint need to check for code? TypeScript focuses on type checking, not code style.

Prettier is supposed to deal with everything related to code format, not code quality.

So it seems Eslint could do what Prettier does, just do code quality checking and formatting checking for Eslint

You don’t need prettier if you think esLint formatting is enough. But there are cases where prettier is needed. Here’s a little demo:

main.js

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

Notice that the indentation in our file is four Spaces.

Install Prettier and ESLint for the project

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

Configure rules in.eslintrc.js:

  1. Allows ES6 and Node syntax
  2. Each line has a maximum length of 80
  1. Indent to 2 Spaces
{
  "extends": ["eslint:recommended"],
  "env": {
    "es6": true,
    "node": true
  },
  "rules": {
    "max-len": ["error", {"code": 80}],
    "indent": ["error", 2]
  } 
}
Copy the code

Then we expect esLint to report length and indentation errors.

run

npx eslint main.js
Copy the code

You can see

Then use –fix to fix the format

npx eslint main.js --fix
Copy the code

At this point we’ll see that the indentation issue has been fixed by ESLint, but the max-len issue remains.

Where prettier is used for formatting:

npx prettier main.js --write
Copy the code

You can see that the max-length problem has also been resolved

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

Prettier solves formatting problems that ESLint –fix cannot fix, so it is recommended that Prettier be used alongside ESLint for best code quality and format checking.

All editor related configurations (line ends, indent styles, indent sizes…) Should be handled by EditorConfig. If a team uses two ides, such as Sublime Text and Visual Studio Code, EditorConfig allows them to define a common indentation mode (space or TAB) in a single file.

Prettier does Prettier mean EditorConfig does prettier do the same thing?

The answer is no, using EditorConfig also avoids useless formatting of the file at save time, because the editor has already formatted it according to EditorConfig’s rules. But the tricky part is making sure Prettier and EditorConfig have the same rules rather than being reconfigured in two separate files.

Formatting conflicts can occur if you want to use ESLint and Prettier together (which I did). ESLint can format code differently from Prettier. Also, using EditorConfig with Prettier might make the configuration redundant. So how do you configure all these tools so that they work well together?

Let Prettier do his job!

In order for Prettier to be used alongside ESLint, the idea is to disable all ESLint rules that would conflict with Prettier (code formatting rules). The eslint-config-prettier package already does this for us

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

The plugin overwrites the configuration in.eslintrc.json from prettier to prevent collisions.

We’ll add Prettier and remove any existing code formats by configuring the extends field in the.eslintrc.json file.

{
  "extends": ["eslint:recommended", "prettier"],
  "env": {
    "es6": true,
    "node": true
  }
}
Copy the code

Note that the order of extend in eslintrc.json is very specific, and that the latter configuration overrides the previous configuration.

Running two commands to lint and format our files isn’t really very convenient. To solve this problem, we will integrate Prettier with ESLint by adding the eslint-plugin-Prettier package. That is, using a command is all we need to do with lint and formatting.

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

Json we will do this by adding prettier to the plugins in eslintrc.json and setting the prettier rule to Error, after which prettier formatting errors are considered ESLint errors.

{
  "extends": ["eslint:recommended", "prettier"],
  "env": {
    "es6": true,
    "node": true
  },
  "rules": {
    "prettier/prettier": "error"
  },
  "plugins": [
    "prettier"
  ]
}
Copy the code

At this point, our file will be in the form of prettier to format, at the same time, we can also use the plugin: prettier/it to replace the original. Eslintrc. Do prettier in the json file configuration specific rules.

Eslintrc. json looks like this:

{
  "extends": ["eslint:recommended", "plugin:prettier/recommended","prettier"],
  "env": {
    "es6": true,
    "node": true
  }
}
Copy the code

Common problems with Prettier and ESlint

At this point, I looked at the configuration of the project and found that the dependency eslint-config-prettier was already configured,

So why is there a conflict? Because we are a typescript project, incorporating the @typescript-ESLint plugin, Prettier requires a two-space indentation, while ESLint requires a four-space indentation, We can see that the @typescript-eslint plugin gave us an error, so we would normally override this rule in.eslintrc.json:

"@typescript-eslint/indent": ["error", 2]
Copy the code

While this only solves its surface problem, the next time there is another rule conflict, we can only continue to add here.

And when they do this, EsLint and Prettier start formatting together, which we don’t like because Prettier is expected to do the formatting.

So ESLint should not format code, and new plug-ins are no exception. Therefore, we need to disable all code formatting rules for our plug-in by adding prettier/ @typescript-esLint to our extends array.

{
  "extends": ["eslint:recommended", "plugin:prettier/recommended","prettier","prettier/@typescript-eslint"],
  "env": {
    "es6": true,
    "node": true
  }
}
Copy the code

Prettier and prettier/ @typescript-esLint go at the end of the extends array because prettier and @typescript-esLint go at the end of the extends array because later configurations override the previous ones. Because of this configuration, one thing that ESLint can be sure of is that prettier doesn’t take away from prettier’s formatting job, prettier throws an error to ESLint if there is a formatting problem.

So let’s summarize

  • Whenever a plug-in is added to ESLint, it must consider the code formatting rules it adds and add the configuration of Prettier (if available) to disable them. In our example, we used prettier/ @typescript-esLint, but we could also use prettier/react or prettier/vue. See the eslint-config-Prettier documentation for a list of supported ESLint plugins.
  • Don’t try to override formatting rules in.eslintrc.json files yourself (this is not the scope of ESLint)
  • If you see your code formatting in two different ways, Prettier and ESLint conflict, it means you have a useless ESLint formatting rule that caused the conflict, and you did not follow the pattern (just letting Prettier do the formatting)

So to solve the first problem, I would configure Prettier / @typescript-esLint in my project to disable @typescript-esLint from prettier and let Prettier do the formatting only.

The original link

Blog.theodo.com/2019/08/emp…

Blog.theodo.com/2019/08/why…

www.benmvp.com/blog/pretti…