English | 简体中文
- Single quotes, Semi
- Share ESLint and Stylelint configurations
- Code lint check based on Airbnb
- Code formatting based on Prettier
- ESLint Flat Config, compose easily
- Easy to integrate, configuration, and custom rules
@flypeng/eslint-config
@flypeng/eslint-config-basic
@flypeng/eslint-config-javascript
@flypeng/eslint-config-typescript
@flypeng/eslint-config-vue
@flypeng/eslint-config-react
@flypeng/eslint-config-other
@flypeng/stylelint-config
pnpm add eslint stylelint prettier @flypeng/eslint-config @flypeng/stylelint-config -D
{
"extends": "@flypeng/eslint-config"
}
With ESM
"type": "module"
inpackage.json
// eslint.config.js
import flypeng from '@flypeng/eslint-config';
export default flypeng();
With CJS
// eslint.config.js
const flypeng = require('@flypeng/eslint-config').default;
module.exports = flypeng();
{
"extends": "@flypeng/stylelint-config"
}
{
"semi": true,
"singleQuote": true,
"bracketSpacing": true,
"printWidth": 120,
"vueIndentScriptAndStyle": false
}
/dist/*
.local
.output.js
/node_modules/**
**/*.svg
**/*.sh
/public/*
**/*.yaml
{
"scripts": {
"lint": "prettier . --write && eslint . && stylelint \"**/*.{css,scss,vue}\"",
"lint:fix": "prettier . --write && eslint . --fix && stylelint --fix \"**/*.{css,scss,sass,vue}\""
}
}
Install VSCode ESLint、Stylelint、Prettier、Prettier ESLint plugins and create .vscode/settings.json
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"eslint.enable": true,
"eslint.useFlatConfig": true, // 启用ESLint新的配置系统
"eslint.format.enable": true,
"eslint.validate": [
"javascript",
"javascriptreact",
"typescript",
"typescriptreact",
"jsx",
"tsx",
"vue",
"html",
"markdown",
"json",
"jsonc",
"json5",
"yaml"
],
"css.validate": false,
"less.validate": false,
"scss.validate": false,
"stylelint.enable": true,
"stylelint.validate": ["css", "less", "scss", "sass", "vue", "postcss"]
}
The configuration of.editorconfig is necessary for team development to ensure that the team editor behaves in a consistent style.
# EditorConfig helps developers define and maintain consistent
# coding styles between different editors and IDEs
# editorconfig.org
root = true
[*]
# We recommend you to keep these unchanged
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
# Change these settings to your own preference
indent_style = space
indent_size = 4
[*.{ts,tsx,js,jsx,json,css,scss,yml,yaml,html,vue,md}]
indent_size = 2
[*.md]
trim_trailing_whitespace = false
If you need to rewrite rules, you probably need to specify files scope, because the rules used by packages other than @flypeng/eslint-config-javascript
are plugins for specific files. If you do not declare the file scope, unexpected errors will occur.
Examples:
// eslint.config.js
import flypeng from '@flypeng/eslint-config';
export default [
...flypeng(),
{
/**
* If you do not declare the file Scope, other files will also refer to this rule.
* But the rules of other files do not use the @ typescript-eslint/eslint-plugin plugin, so an error will be reported during Lint.
* Reference detail: https://github.com/eslint/eslint/issues/17485
*/
files: ['**/*.ts'],
rules: {
'@typescript-eslint/no-explicit-any': 'off',
},
},
];
There is a lot of discussion on the web about using Prettier for code formatting, and it is true that some aspects of Prettier's formatting are a bit mandatory, resulting in code that is less readable or not in your preferred style of code.
One of Why I don't use Prettier written by Anthony Fu accepts why Prettier is not applicable. See what he has to say.
Why did I enable Prettier for code formatting in @flypeng/eslint-config
?
There are two main things I took into account:
First, if you are an individual developer and you have a good grasp of the overall project code style, you can consider not using Prettier, but if you are a team developer, you can't guarantee that your code style will be accepted by the other team members and it will lead to a variety of code styles for the project as a whole. So this time you should consider using Prettier to force the unified code style.
Second: ESLint main responsibility is to verify the code rather than the code format , so for simple checksum automatic repair can be a certain degree of enlightenment to the role of formatting . But for the overall project code style ESLint does not guarantee that Prettier's main responsibility is to unify the overall style.
Based on the above two points, I decided to open the use of Prettier.
V2 is a refactoring of V1 in order to adapt ESLint's flat configuration and use Prettier as a code formatting tool.
If you need to adapt ESLint's flattened configuration, then all the packages you use internally need to use the new version of the flattened configuration. Fortunately, ESLint has provided an adaptation scheme, eslintrc, to convert the old configuration to the new one.