When working on projects, we often encounter the following two problems:
- There are a lot of wavy lines in the code, which are not only uncomfortable to look at, but also affect the code quality.
- I only changed one line of code, but diff made a lot of difference.
Although these details seem small in team projects, they have a subtle impact on team efficiency. There are tools we can use to establish good practices early in a project.
Prettier, Prettier, ESLint, Prettier this article briefly discusses the relationship between ESLint and Prettier, the relationship between Prettier and his editor, and the boundary between ESLint and Prettier.
ESLint
ESLint is an NPM library that identifies front-end code and alerts you for code that doesn’t conform to the specification. We could create a new project to experiment with, with the project name of let’s say Lint.
mkdir lint
cd lint
yarn init
Copy the code
Then create a new index.js and write a function.
function hello() {
let name = "jay"
console.log("hello there")}Copy the code
In the case of vscode, the editor does not tell you anything about the code after some basic features of vscode are disabled.
Now let’s install ESLint in our project.
yarn add eslint --dev
Copy the code
Lock the version number of ESLint in package.json to prevent the rest of the team from generating inconsistent prompts due to different version numbers.
Generate configuration files using the built-in commands of ESLint (.eslintrc.js)
⚠️ if you type eslint directly, you may be prompted that the command cannot find bash: eslint: /node_modules/. Bin is added to the PATH environment variable, which means the system automatically finds the./node_modules/. Bin folder when executing the command. Take bash as an example.
vim ~/.bashrc
Copy the code
Or run it directly./node_modules/.bin/eslint --init
Same effect.
After you have generated the configuration file, run the command
eslint index.js
Copy the code
Eslint will alert us to code that doesn’t conform to the specification
But in a formal project you can’t always use a command to check your code, so vscode’s eslint plugin is needed to help.
ESLint plug-in
ESLint plugins are different from ESLint plugins. They integrate ESLint functionality into the editor (for example, vscode), allowing non-compliance to be flagged as we write code. This works only if the ESLint libraries are installed locally or globally in the project.
After ESLint is enabled, you can see the prompt. Note that eslint is already enabled in the lower right corner of vscode.
Husky- Mandatory check before submission
In order to prevent bad code from being submitted to the repository, we can use Git’s hook to do a check before submission. For example, do a code check at pre-commit time. See this article for more information on Git Hooks. However, it is not easy to make git hook by yourself, so we can use Husky to help us.
Husky is a git hook helper that helps you maintain hook commands. The following uses Husky V6 as an example to illustrate the installation process.
yarn add husky --dev
husky install
Copy the code
Add a script to package.json so that new users can automatically activate Git hook after YARN install
"scripts": {
"prepare": "husky install"
},
Copy the code
Add the hook
A.husky folder is generated after running husky Install
We can use husky add
[CMD] to add a hook
husky add .husky/pre-commit "npx eslint index.js"
Copy the code
After running the above command, you will add a pre-commit file to the.husky folder, which contains the added command.
NPX eslint index.js will be executed when we submit the code and a message will be sent indicating that the code check failed.
Lint-Staged
The pre-commit callback setup succeeded 😎, but we ran into another problem, if NPX esLint SRC /* was executed to check all files before each commit, it would take a lot of time just to check, which was obviously not reasonable. Lint-staged libraries are designed to do just that, by simply checking those submitted files instead of all of them.
Install the Lint – Staged
yarn add lint-staged --dev
Copy the code
Add one to package.json
"scripts": {
"prepare": "husky install"
},
/ / increase
"lint-staged": {
"*.{js,jsx}": "eslint"
},
"devDependencies": {
"eslint": "7.28.0"."husky": "^ 6.0.0"."lint-staged": "^ 11.0.0"
}
Copy the code
NPX Lint-staged commands were changed from the previously added. Husky /pre-commit file
When you commit your code at this point, the hook will execute Lint-staged commands and only the files submitted will be checked.
So far, we’ve used ESLint to help us solve code quality problems.
For code formatting questions, such as whether to add to the end; Number, whether to use double quotes “” or single quotes “for strings, whether to wrap long objects… These issues don’t affect code quality, but if everyone’s format is different, the second problem at the beginning of this article can occur, and ultimately affect team effectiveness. Prettier needed her help.
Prettier
Prettier is similar to ESLint in that there is a Prettier library and a Prettier plugin.
We refer to the official website to introduce how to install
yarn add --dev --exact prettier
Copy the code
⚠️ it is important to lock the version number here. Make sure everyone on the team is on the same version. ⚠️
Prettierrc. json and write a rule such as:
{
"singleQuote": true
}
Copy the code
Create.prettierIgnore files and tell command lines and editors to ignore formatting them, for example
# Ignore artifacts:
build
coverage
Copy the code
Global formatting code
prettier --write .
Copy the code
Or format a file
prettier --write src/index.js
Copy the code
As with ESLint, in a formal project you can’t format code every time you use a command, so you need to install a plugin to let the editor format it for you automatically.
Prettier plug-in
Installing the Prettier plug-in (using VScode as an example)
Edit VScode settings.json to set Prettier as the default formatting tool, and set formatOnSave as the formatting code
{
"editor.defaultFormatter": "esbenp.prettier-vscode"."[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.formatOnSave": true
}
Copy the code
Press CTRL+S to save the code and the code will be automatically formatted 👍
⚠️ Note how a Prettier plugin differs from the ESLint plugin. Prettier does not need the ESLint plugin to run without having the ESLint library installed locally. If the Prettier library is not installed locally in your project, but the editor simply installs the Prettier plug-in, the editor can still format the code. Although Prettier is not recommended, officials emphasize the need to install the Prettier library locally so that editors can format the same version using the local library, ⚠️
Configuration file for Prettier
Configuration files in multiple places affect Prettier configuration. For example, vscode Settings,.prettierrc.json,.editorConfig. Their priority is (the one on the left has the highest priority):
Json file in the same directory ->. Prettierrc. json file in the root directory ->. Editorconfig file -> vscode Settings
Configuration of the pre – commit
We already set the pre-commit callback when we introduced ESLint, now we add Prettier as well.
Json file: “**/*”: “prettier –write –ignore-unknown” edited package.json file to add “**/*”: “prettier –write –ignore-unknown” from lint-staged
⚠️ Make sure the ESlint command precedes Prettier.⚠️
This ensures that the code is formatted correctly even if the editor does not configure the prettier plug-in.
The boundary between ESLint and Prettier
In addition to pointing out code quality, ESLint can also point out and fix formatting problems, just as Prettier does, and some rules conflict with each other.
We tend to let Prettier handle all format-related issues and ESLint handle all code quality issues, with each side doing what they’re good at. Prettier’s website for Prettier
When you encounter conflicting rules, you can simply turn off rules on one side of ESLint. Prettier maintains the rule on Prettier’s website, just extend it into ESLint’s configuration file. See eslint – config – prettier
End 🎉