@uplus/eslint-config-base v1.1.2

U+ ESLint config base

A shareable ESLint configuration file

TypeScript

For linting TypeScript project use @uplus/eslint-config-typescript.

Installation

1. install ESLint and dependencies

   yarn add --dev eslint@^5 @uplus/eslint-config-base

2. create/modify .eslintrc.js file in root of your project and paste following snippet inside

   // .eslintrc.js
   module.exports = {
     extends: ['@uplus/eslint-config-base'],
   }

IDE support

Most IDE's has support for eslint, which will highlight linting errors in source code. It is strongly recommended to use these extensions since it improves your workflow significantly.

• setting ESLint in VSCode
• setting ESLint in WebStorm

Setup QA in project

After installation, follow these steps to unleash the full power of ESLint.

1. Run all of these steps in separated GIT branch.

2. Create .eslintignore file in root of your project. It works similarly to .gitignore, all listed paths will be ignored by eslint CLI or IDE extensions, but beware that the syntax is different from .gitignore. All line must be a glob relative to .eslintignore. Please, read the .eslintignore documentation.

   Your .eslintignore might look like this

   # ignore node_modules directory anywhere
   **/node_modules/*
   # ignore build directory next to .eslintignore
   build/*

3. Create lint script in package.json like this

   // package.json
   {
     "scripts": {
       "lint": "eslint --ext .js,.jsx ."
     }
   }

   Note: ESLint by default checks only .js file extensions, so we use --ext option to check also .jsx and we check all files from root directory with period ., excluding only files marked in .eslintignore.

4. Run yarn lint in terminal and check reported errors and warnings. If it contains files that you dont wish to check, eg. generated code, improve your .eslintignore. Once you are happy with your .eslintignore setup, commit your changes.

5. Some errors could be fixed automatically by ESLint and it will be reported in ESLint output. Run yarn lint --fix to perform this automatic fixes and then check git diff of made changes. If everything is OK, commit changes.

6. Manually resolve errors that cannot be automatically fixed. Run yarn lint --quiet to report errors only and then fix errors or disable rules with inline comments.

7. You may also suppress some rules in .eslintconfig.js, but think twice before you do so. If you thing some rule does not makes sense, eg. decreases code clean and readability, please, open discussion in Github issue tracker.

8. In case you are using non standard module resolution scheme, eg. absolute path components/ resolved to src/components, you must install and setup resolvers for eslint-plugin-import, there is resolver for webpack for Webpack aliases or resolver for babel for babel aliases. In case your resolution schema is more complicated and not supported by resolvers, you will need to disable eslint-plugin-import since it wont work for you.

9. If you encounter some difficulties, don't hesitate to open ticket on Github issue tracker.

10. As you correct all errors, commit your changes. Congratulation, you have now 100% fixed project. You should also fix all warning, but it is not that much important, so we can continue to next step.

11. To keep your project in a good shape, install lint-staged and set it to lint all files before git commit. Lint-staged is smart, it will only check files that was changed since last commit, so it will be pretty fast.

    Set lint-staged it in package.json like this

    // package.json
    {
      "husky": {
        "hooks": {
          "pre-commit": "lint-staged"
        }
      },
      "lint-staged": {
        "**/*.j{s,sx}": ["eslint --fix --quiet"]
      }
    }

    Now eslint will run prior to commit on all files in GIT staging area with .js or .jsx extension and in case of any linting errors, it will print the errors and prevent the commit to finish. All team members must fix or explicitly suppress linting errors to commit their work and suppressed errors are easy to spot during code review.

12. You may sometimes need to quickly commit changes with errors, eg. because you need to switch into another branch. For this scenario, you can run git commit with --no-verify flag tu skip linting. This is why you should run eslint also as part of continuous integration (CI) tests, because some people may misuse the --no-verify flag. Please, setup CI to run yarn lint as one of initial steps.

13. You should also install and use prettier to enforce same formatting rules and to overcome bloated GIT history by changed formatting of code. Check pretty-quick library, which is like lint-staged for formatting code.

    With pretty-quick your package.json will look like this

    // package.json
    {
      "husky": {
        "hooks": {
          "pre-commit": "lint-staged && pretty-quick --staged"
        }
      },
      "lint-staged": {
        "**/*.j{s,sx}": ["eslint --fix --quiet"]
      }
    }