[Bug?]: yarn rw lint fails using local eslint config with typed linting rules after RW 8 upgrade

[Philzen]

What's not working?

We recently added an eslintrc.json to our project as described here. We did that b/c we like to have our named imports sorted (sort-imports) and enforce types to be explicitly imported as such (@typescript-eslint/consistent-type-imports).

Now after the upgrade from RW 7 to 8.4.1 running yarn rw lint throws:

=============

WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.

You may find that it works just fine, or you may not.

SUPPORTED TYPESCRIPT VERSIONS: >=4.7.4 <5.6.0

YOUR TYPESCRIPT VERSION: 5.6.2

Please only submit bug reports when using the officially supported version.

=============

Oops! Something went wrong! :(

ESLint: 8.57.1

Error: Error while loading rule '@typescript-eslint/consistent-type-imports': You have used a rule which requires parserServices to be generated. You must therefore provide a value for the "parserOptions.project" property for @typescript-eslint/parser.
Parser: ./node_modules/@babel/eslint-parser/lib/index.cjs
Note: detected a parser other than @typescript-eslint/parser. Make sure the parser is configured to forward "parserOptions.project" to @typescript-eslint/parser.
Occurred while linting ./web/src/i18n.js
    at throwError (./node_modules/@typescript-eslint/utils/dist/eslint-utils/getParserServices.js:38:11)
    at getParserServices (./node_modules/@typescript-eslint/utils/dist/eslint-utils/getParserServices.js:21:9)
    at create (./node_modules/@typescript-eslint/eslint-plugin/dist/rules/consistent-type-imports.js:88:68)
    at Object.create (./node_modules/@typescript-eslint/utils/dist/eslint-utils/RuleCreator.js:31:20)
    at createRuleListeners (./node_modules/eslint/lib/linter/linter.js:895:21)
    at ./node_modules/eslint/lib/linter/linter.js:1066:110
    at Array.forEach (<anonymous>)
    at runRules (./node_modules/eslint/lib/linter/linter.js:1003:34)
    at Linter._verifyWithoutProcessors (./node_modules/eslint/lib/linter/linter.js:1355:31)
    at Linter._verifyWithConfigArray (./node_modules/eslint/lib/linter/linter.js:1807:21)
    at Linter.verify (./node_modules/eslint/lib/linter/linter.js:1437:65)
    at Linter.verifyAndFix (./node_modules/eslint/lib/linter/linter.js:2068:29)
    at verifyText (./node_modules/eslint/lib/cli-engine/cli-engine.js:254:48)
    at CLIEngine.executeOnFiles (./node_modules/eslint/lib/cli-engine/cli-engine.js:834:28)
    at ESLint.lintFiles (./node_modules/eslint/lib/eslint/eslint.js:551:23)
    at Object.execute (./node_modules/eslint/lib/cli.js:421:36)
    at async main (./node_modules/eslint/bin/eslint.js:152:22)

I tried all kinds of settings for parserOptions mentioned in the typed linting docs to no avail. However, adding

  "parser": "@typescript-eslint/parser",

to our .eslintrc.json makes the error go away – however i'm not sure this is really intended by @redwoodjs/eslint-config, as i would assume the Redwood team wants to employ @babel/eslint-parser here for a good reason, which probably was brought in via either #10911 or #11235.

How do we reproduce the bug?

Have any custom eslint config (js/cjs/json/whathaveyou) in your project that includes the rule @typescript-eslint/consistent-type-imports, for example, our .eslintrc.json looks as follows:

{
  "$schema": "https://json.schemastore.org/eslintrc.json",
  "extends": ["@redwoodjs/eslint-config"],
  "ignorePatterns": ["!.storybook/"],
  "root": true,
  "rules": {
    "sort-imports": [
      "error",
      {
        "ignoreDeclarationSort": true,
        "allowSeparatedGroups": true
      }
    ],
    "@typescript-eslint/consistent-type-imports": [
      "error",
      {
        "prefer": "type-imports"
      }
    ]
  }
}

What's your environment? (If it applies)

System:
    OS: Linux 6.6 Manjaro Linux
    Shell: 5.2.37 - /bin/bash
  Binaries:
    Node: 20.16.0 - /tmp/xfs-83057bbe/node
    Yarn: 4.4.0 - /tmp/xfs-83057bbe/yarn
  Databases:
    SQLite: 3.46.1 - /usr/bin/sqlite3
  npmPackages:
    @redwoodjs/auth-dbauth-setup: 8.4.1 => 8.4.1 
    @redwoodjs/cli-storybook-vite: 8.4.1 => 8.4.1 
    @redwoodjs/core: 8.4.1 => 8.4.1 
    @redwoodjs/project-config: 8.4.1 => 8.4.1

Are you interested in working on this?

• I'm interested in working on this

[Philzen]

So i found a different workaround to get rid of the error

Error: Error while loading rule '@typescript-eslint/consistent-type-imports': You have used a rule which requires parserServices to be generated. You must therefore provide a value for the "parserOptions.project" property for @typescript-eslint/parser.
Parser: ./node_modules/@babel/eslint-parser/lib/index.cjs
Note: detected a parser other than @typescript-eslint/parser. Make sure the parser is configured to forward "parserOptions.project" to @typescript-eslint/parser.

… without changing the parser for the project. Any @typescript-eslint/* rules need to go into the "overrides" section matching the "files"-pattern in https://github.com/redwoodjs/redwood/blob/v8.4.2/packages/eslint-config/shared.js#L151-L169

So, when upgrading to v8, any @typescript-eslint/* rule configs need to be moved from the "rules" section into the "overrides" like this:

{
  "$schema": "https://json.schemastore.org/eslintrc.json",
  "extends": ["@redwoodjs/eslint-config"],
+  "overrides": [
+    {
+      "files": ["*.ts", "*.tsx"],
+      "rules": {
+        "@typescript-eslint/consistent-type-imports": [
+          "error", { 
+            "prefer": "type-imports" 
+          }
+        ]
+      }
+    }
+  ],
  "root": true,
  "rules": {
    "sort-imports": [
      "error",
      {
        "ignoreDeclarationSort": true,
        "allowSeparatedGroups": true
      }
    ],
-    "@typescript-eslint/consistent-type-imports": [
-      "error",
-      {
-        "prefer": "type-imports"
-      }
-    ]
  }
}

While i'm happy to have found a workaround that works w/o altering the main parser, i still would have loved to understand what exactly is the root-cause of this, i suspect it's some change in v7 or v8 that just is not obvious to me.

In order to close this ticket, i'm wondering if there's anything that can be done to the eslint-config to make it work without any adjustments?

If not, and this adjustment simply is a necessity now, i believe we should include it in the upgrade guide and also the eslint-config README.md

[Tobbe]

I also wish I understood the eslint stuff better. There's the RW framework vs RW project split. There's the new "flat config" stuff. There's typed linting. I just don't have a good understanding of the full picture right now 🙁

[Philzen]

I just added the rule "@typescript-eslint/no-import-type-side-effects": "error" to my project and was expecting it to also throw the error when not included in the "overrides" array. But no: it works fine.

So i started to investigate – this issue in the typescript repo (which had a fix for it shipped with v8.4.0) says the error shouldn't be thrown in the first place for a similar rule than the offending @typescript-eslint/consistent-type-imports.

I will check if this maybe is fixed with #11878 and if it isn't will probably open an issue over at https://github.com/typescript-eslint/typescript-eslint as helpful information on the error at hand is still hard to come by.

[Philzen]

Hooray! Just ran rw lint in my project with the unaltered .eslintrc.json against my fix branch for #11878 – and it ran w/o any hiccups 🚀

So this apparently was some sort of bug in @typescript/eslint that was fixed between v8.5.0 and v8.19.0 … not sure what exactly, however i'm very happy it is gone 🕺

I did another test against main to confirm and was confused to find the error still gone. Bisecting my project a bit it turned out i had just converted web/i18.js to typescript in a recent commit. Revisiting the original error message it clearly said that was where it failed:

Occurred while linting ./web/src/i18n.js

So getting rid of the last *.js file in the web side also makes the error go away. Strangely, i still have many *.js files in the api side, which it does lint correctly, but doesn't throw the error. So it must probably be something in @redwoodjs/eslint-config that affects only the web-side which we could maybe fix there.