ESLint configuration presets
npm install --save-dev @captive/eslint-config
For most kind of project, just edit eslintrc.json
and add default configuration
{
"extends": [
"@captive/eslint-config"
]
}
Features :
-
ES
andTS
validation JSON
YAML
-
Prettier
formatting -
JSX
andReact
syntax validation -
Jest
tests VueJS
Cypress
For most kind of project, just edit eslintrc.json
and cherry pick only configurations
{
"root": true,
"extends": [
"@captive/eslint-config/dist/react",
"@captive/eslint-config/dist/ts",
// include more configurations here
]
//...
}
Available configurations :
-
@captive/eslint-config/dist/es
: for ECMA Script (ES) files -
@captive/eslint-config/dist/jest
: for jest environment tests -
@captive/eslint-config/dist/json
: for jest environment tests -
@captive/eslint-config/dist/react
: for react capability -
@captive/eslint-config/dist/ts
: for typescript files
This is a recommended way of migrating from another configuration / no configuration. The aim is to setup the shared configuration as soon as possible and progressively fix all errors.
All modifications should be :
- iterative : move safely from a step to another
- easy to review : the smallest changes possible
- safe : avoid touching business code if there is a chance that it could introduce regression
- Add the configuration your eslint configuration file (follow Usage section)
- Disable temporarily each rule that returns an error
-
Get all the errors from eslint
> yarn eslint . path/to/my-project/file.js 1:1 error 'foo' is not defined no-undef # ...
-
Set each rule to
off
{ "rules": { "no-undef": "off" } }
-
Run again eslint and check that no errors are reported
-
Ship the code (Commit, Push, Merge, ...)
-
- For each error iterate as the following :
- Enable the rule (remove the
off
line in the eslint configuration) - Analyze the type of error :
- When fixable and no breaking change could be introduced,
then run
eslint --fix
- When the error is pretty obvious to fix manually, then correct manually all files
- When the code is unsafe by nature or should not be changed (no tests, highly sensitive code),
then the developer could take responsibility to ignore the rule using
// eslint-disable-line ...
and// eslint-disable-next-line ...
- When the rule seems non relevant / impossible to fix in most cases, then post an issue on the
eslint-config
repository with your use case
- When fixable and no breaking change could be introduced,
then run
- Ship the code (Commit, Push, Merge, ...)
- Enable the rule (remove the
MIT © Julien Polo julien.polo@captive.fr
@captive/eslint-config is maintained and funded by Captive. The names and logos for captive are trademarks of captive-studio.
We love open source software! See our other projects or hire us to design, develop, and grow your product.