@captive/eslint-config NPM

Captive ESLint configuration (@captive/eslint-config)

ESLint configuration presets

Installation

npm install --save-dev @captive/eslint-config

Usage

Default JS/TS project

For most kind of project, just edit eslintrc.json and add default configuration

{
  "extends": [
    "@captive/eslint-config"
  ]
}

Features :

ES and TS validation
JSON
YAML
Prettier formatting
JSX and React syntax validation
Jest tests
VueJS
Cypress

Custom project

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

Migration Guide

Intention

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

Content

Add the configuration your eslint configuration file (follow Usage section)
Disable temporarily each rule that returns an error
1. Get all the errors from eslint
```
> yarn eslint .
path/to/my-project/file.js
1:1  error  'foo' is not defined  no-undef

# ...
```
2. Set each rule to off
```
{
    "rules": {
        "no-undef": "off"    
    }
}  
```
3. Run again eslint and check that no errors are reported
4. Ship the code (Commit, Push, Merge, ...)
For each error iterate as the following :
1. Enable the rule (remove the off line in the eslint configuration)
2. 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
3. Ship the code (Commit, Push, Merge, ...)