How to incrementally apply strict tsconfig and ESLint rules using reviewdog

Overview

As a project progresses, you may gain insights from failures or need to add powerful ESLint rules due to changes in the project phase. However, adding rules that have the following characteristics mid-project can be difficult because there are too many files to change manually:

• The number of errors against existing code exceeds 100.
• Automatic fixes via --fix are not provided.

In this article, referring to Improving code quality without stopping the service: How to continue safe development with TypeScript + React - Logmi Tech, I will introduce a method to gradually apply strict tsconfig and ESLint rules using reviewdog.

Method

From here on, I will explain using ESLint rules as an example. Similar settings are possible for tsconfig and other tools.

https://github.com/reviewdog/reviewdog

reviewdog is a tool that posts the output of linter tools as review comments using GitHub Checks or similar services. reviewdog has a feature to filter linter output to only the lines (or files) added or deleted in a pull request.

By using this reviewdog feature to filter the output of stricter ESLint rules to only the files added or deleted in a pull request, we can gradually improve the project's code quality.
Specifically, we prepare a .eslintrc.strict.js that adds stricter rules to the regular .eslintrc.js. We then pass this .eslintrc.strict.js to the ESLint config option and filter its output with reviewdog.

I will explain the detailed procedure using a sample repository.

Sample Repository

Introduction to the Code

Here is the sample repository.
https://github.com/odan-sandbox/reviewdog-later-strict-example

In this case, I have added "no-return-await": "error" to .eslintrc.strict.js.

.eslintrc.strict.js

module.exports = {
  extends: "./.eslintrc.js",
  rules: {
    "no-return-await": "error"
  }
}

Prepare the reviewdog configuration file .reviewdog.yml.

.reviewdog.yml

runner:
  tsc:
    cmd: yarn --silent test:build --project tsconfig.strict.json --noEmit
    format: tsc
  eslint:
    cmd: yarn --silent test:lint --config ./.eslintrc.strict.js
    format: eslint

If you are using yarn, the text output by yarn can be distracting, so add the --silent option.

Finally, execute reviewdog in your CI.

.github/workflows/strict.yml

    - name: run eslint strict
      run: |
        reviewdog -runners=eslint -diff="git diff master" -fail-on-error -reporter=github-pr-check -filter-mode=file
      env:
        REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}

-filter-mode=file is an option that filters the files added or deleted in a pull request.

Example of Operation

This pull request assumes a case where a file that fails linting with the strict ESLint rules has been edited.
https://github.com/odan-sandbox/reviewdog-later-strict-example/pull/18

As shown in the image below, the stricter ESLint rules were executed on the modified no-strict-file.ts, and errors were generated.

no-strict-file-no-update.ts, which contains the same content as no-strict-file.ts, is not flagged by the stricter ESLint rules.

Conclusion

I have introduced an example of gradually applying strict ESLint rules by using reviewdog's feature to filter ESLint results to only the files changed in a pull request.

In practice, it might be beneficial to add rules as warning in .eslintrc.js that are added as error in .eslintrc.strict.js, so that you can notice the stricter rules while editing the code.