writing background:
After reading most of the articles about eslint on the Internet, I feel that none of them are very satisfying to my needs, and many articles feel that they have been copied from time to time, and I feel like I have become a configuration engineer. My needs: 1. I have no sense when writing code, don’t want me to deal with eslint errors while writing code, which will seriously affect my thinking 2. No configuration is needed, I don’t want to write too much eslint configuration 3. Submit Help me check the code quality from time to time, the plug-ins that can be modified can be modified directly, and the plug-ins that cannot be modified can be modified manually. I have
referred to many solutions. The approximate solution is 1. Do not eslint when saving, 2. Use a standard eslint library to Standard code 3. Check the code when git commit
Here use the vue2 project as a reference, and the steps to add the vue3 project are exactly the same.
The following is the solution: There are two situations:
1. The project has not been created yet, create a project through vue-cli and add eslint (the simplest, highly recommended)
2. The vue project has been created, but want to add eslint go in (slightly troublesome)
Situation 1: The project has not been created yet, create a project through vue-cli and add eslint
Pre-environment:
1. node environment, select a version to download to the computer, and confirm all the way. Official website download: https://nodejs.org/en , download and install node, which comes with npm package management tool, you can use npm to install things. You can enter node -v and npm -v in the console to see if there is a version number. If there is a version number, it means that the installation is successful.
2. Download vue-cli: npm install -g vue-cli After running this command, enter vue -V in the console (note that V is capitalized). There is a version number indicating that the installation of vue scaffolding is successful. Then enter the main steps. Main steps
: Create a project: vue create demo_init_eslint
Select manually which functions
to install and add all the functions you need 1. Select vue version 2.babel 3. Routing 4.vuex 5.css preprocessing 6.
The other unselected options for eslint are: ts, pwa support, unit test, end-to-end test
Here is to ask you what is the version of Vue , choose version 2.x
Here are three questions, ask respectively:
whether Use the history pattern as your routing pattern ? Generally choose yes,
please choose a css preprocessor , you can choose less or sass, depending on which one you are more familiar with,
choose an eslint configuration , here we choose eslint using standard rules.
Please select the trigger timing of eslint? :
1. Trigger eslint when saving
2. When git commit, fix the problem and perform eslint detection
Here we choose to remove the first one and open the second one. (The main reason is that I don’t want to solve the eslint problem during development. If there is a format problem, I will automatically fix it for me when I git commit. If I can’t fix it, I will fix it manually.) There are two problems here, namely: your babel,
eslint
and Are some other configuration files placed in different files or in package.json? Here we choose to put it in a different file.
Do you want to save this configuration so that you can create a project next time? It means that a configuration will be generated for you to choose. Next time you choose this configuration directly, you don’t need to answer these questions anymore. You can install it directly according to the answer of this configuration. Choose n here, and choose not to save (because I have already saved it on my computer, you can also choose to save it, and you can directly choose this configuration when you create a project next time).
So far: your project has successfully added standard eslint, and can automatically detect errors and submit code when git commit.
Test it: Write some code casually:
Finally, let’s see what the code submitted to the local warehouse looks like after being repaired by eslint:
let is automatically replaced with const
at the end; this whole set is removed
, which is very in line with my development needs . The advantage of vue-cli is that it is very friendly to development.
Supplementary note:
The first point: Detailed explanation of the .editorconfig file https://www.jianshu.com/p/f92fde2c0824
is used to unify the newline and indentation storage format of the configuration editor
indent_style = space # 输入的 tab 都用空格代替
indent_size = 2 # 一个 tab 用 2 个空格代替
end_of_line = lf # 换行符使用 unix 的换行符 \n
charset = utf-8 # 字符编码 utf-8
trim_trailing_whitespace = true # 去掉每行末尾的空格
insert_final_newline = true # 每个文件末尾都加一个空行
[*.md]
trim_trailing_whitespace = false # .md 文件不去掉每行末尾的空格
The second point: .eslintrc.js file, you can configure custom rules yourself .
But my principle is to use the standard standard, and follow this standard. In fact, I don't have so many requirements for the code format, mainly 1. Do not have a semicolon at the end, 2. Use two spaces for indentation, 3. Use single quotation marks 4. Newline character 5. Leave a line at the end of the file 6. Everything else follows the standard.. These are all configured in the standard standard or in the editorconfig, so I don't need to change anything. . If your team feels that it needs to have its own rules, you can define it yourself in rules. But I don't recommend you to define your own rules on the basis of standard. You should expand your own rules based on a relatively small rule such as ('plugin:vue/recommended','eslint:recommended'). The third point:
git Why does the formatting of eslint be triggered when committing?
gitHooks will execute lint-staged before committing, and then running lint-staged is equivalent to executing npm run lint, allowing eslint to fix errors that can be automatically repaired by the plug-in (the role of husky is also to trigger lint-staged before committing, here The role of gitHooks is equivalent to husky)
The fourth point: why use the standard standard? I just want to use the Airbnb standard
A: Whatever, use the standard standard, but I prefer this slightly looser code inspection. You can also choose the Airbnb standard during initialization.
Fifth point: Why not install prettier? It is said on the Internet that eslint is used to detect the code and let prettier format the code.
Answer: The benevolent see benevolence, the wise see wisdom. There are several reasons for this:
1. A team of 3-5 people is unnecessary and troublesome. Teams of 10 or more are required.
2. eslint also comes with formatting codes. Although prettier is more powerful, in fact, many codes that eslint cannot repair cannot be repaired by prettier, so we have to manually repair them ourselves.
3. In fact, the reason why you really need prettier is that you can format it locally, but after submitting it, only the part of the code you wrote will be submitted by yourself, and if you change the part of the code in the local format, the submitter will still be someone else of. This is the biggest advantage of prettier, it will not change the git committer. Another advantage is that eslint is only valid for the js part of vue, and there is no verification for template and css. Based on this, it is upgraded and used with prettier to ensure the complete unity of style.
For example, using the project we just generated above, suppose a wrote such a code. But because there is a bug in this code, we modify the code by ourselves. While modifying, we wrote some divs in the template, and then formatted it when we thought it was messy.
Then after you submit, you will find that the tags in the code template written by a become what you wrote. The author becomes you. Because you changed the format of this code (maybe you will be blamed in the future).
The code written
by a has a bug, so you modify it, but you format it with prettier or vetur
From the two submissions: because you formatted, the code written by the other party became yours. . (Shocked, obviously it wasn't written by me)
Ever since, you need a unified formatting plugin: prettier. In this case, since you and your colleagues are using prettier for formatting, no matter whether you use vuter or prettier for formatting locally, you will finally format again with the installed prettier before git commit, ensuring the team code style The complete unity, this is the reason why prettier is really needed
So do you really need prettier?
1. If you don't care about changing some of the submitters, you don't need to install it at all.
2. You can also write the code without formatting, or just format the selected content, which avoids this problem.
3. Although prettier can unify the code style, I don’t really like its formatting in the template , In contrast, I prefer to use vue2's vuter and vue3's volar plug-ins to format, which looks more beautiful.
4. The benevolent sees the benevolent and the wise sees the wisdom. I can't make a decision for you, but I will tell you how to join prettier
So how to add prettier?
1. Install the necessary packages
- prettier - prettier body
- eslint-config-prettier - Turn off rules in ESLint that conflict with Prettier
- eslint-plugin-prettier - Set Prettier rules into ESLint rules
npm i prettier eslint-config-prettier@6 eslint-plugin-prettier@3 -D
Error resolution during installation: It is ok to specify a large version. This error is obviously caused by the incorrect version matching of eslint and eslint-plugin-prettier
2. Add a .prettierrc.js file in the root directory, the content is as follows :
module.exports = {
tabWidth: 4, // 指定每个缩进级别的空格数<int>，默认2
useTabs: false, // 用制表符而不是空格缩进行<bool>，默认false
printWidth: 300, //一行的字符数，如果超过会进行换行，默认为80
singleQuote: true, //字符串是否使用单引号，默认为false，使用双引号
endOfLine: 'auto', //避免报错delete (cr)的错
proseWrap: 'always',
semi: false, // 不加分号
trailingComma: 'none', // 结尾处不加逗号
htmlWhitespaceSensitivity: 'ignore', // 忽略'>'下落问题
}
3. Modify the ESLint configuration to make Eslint compatible with the Prettier rule
plugin:prettier/recommended The configuration needs to be noted that it must be placed at the end. Because the rules introduced later in extends will override the previous rules. That is to say, you can define your own style code in .prettierrc.js. At that time, the local prettier plug-in will be formatted according to this file, and the prettier installed by the project will also be formatted according to this file. And where the eslint style conflicts with the prettier style, the prettier will be the main one
const {
defineConfig } = require('eslint-define-config')
module.exports = defineConfig({
/// ...
extends: [
'plugin:vue/essential',
'@vue/standard'
'plugin:prettier/recommended'
],
// ...
})
Case 1 project demo source address (with prettier added): https://github.com/rui-rui-an/demo_init_eslint_prettier
Case 1 project demo source address (without prettier): https://github.com/rui-rui -an /eslint_init_eslint_standard
Situation 2: The vue2 project has been created, but I want to add eslint to it (a little troublesome)
Another blog is written, please jump to view, the address is: https://blog.csdn.net/weixin_43239880/article/details/130263271?spm=1001.2014.3001.5501