@usertech/eslint-config-typescript

ESLint preset enforcing same conventions in U+ projects

Usage no npm install needed!

<script type="module">
  import usertechEslintConfigTypescript from 'https://cdn.skypack.dev/@usertech/eslint-config-typescript';
</script>

README

U+ ESLint config TypeScript

A shareable ESLint configuration file

ESLint vs TSLint

This config is fully capable of linting TypeScript files. You may drop TSLint in your project since TypeScript team now officially supports ESLint.

Installation

  1. install ESLint and dependencies

    yarn add --dev eslint@^5 @usertech/eslint-config-typescript

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

    module.exports = {
      extends: ["@usertech/eslint-config-typescript"]
    };
    

IDE Support

Most IDE's has support for eslint, which will highlight linting errors in sourcecode.

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,.ts,.tsx ."
      }
    }
    

    Note: ESLint by default checks only .js file extensions, so we use --ext option to check also TypeScript and .jsx files 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 doso. 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, dont 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 importatnt, 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": {
        "**/*.[jt]{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 formating 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": {
        "**/*.[jt]{s,sx}": ["eslint --fix --quiet"]
      }
    }
    

    With this setup, prior to commit, changed files will be validated with ESLint and formatted with prettier. Please, check Prettier, the opinionated formater to instructions how to install and set it up. Prettier also nicely integrates with IDE and it is strongly recommend to use this integration.

    This ESLint config is prepared to integrate with prettier, so ESLint shall not report formatting errors handled by prettier (eg. ESLint will not check max lenght of line if prettier controls that).