Error generating `parserServices` for eslint plugin `@typescript-eslint`

[r0skar]

Versions:

• prettier-eslint version: 8.8.2
• node version: 11.9.0
• yarn version: 1.13.0

Have you followed the debugging tips?

Yes

Relevant code or config

.eslintrc.js

parser: `@typescript-eslint/parser`,
parserOptions: {
  project: `./tsconfig.json`
},
rules: {
  '@typescript-eslint/no-unnecessary-type-assertion': 2
}

What I did: Run prettier (via VSCode`s FormatOnSave hook).

What happened:

Error while loading rule '@typescript-eslint/no-unnecessary-type-assertion'/home/oskar/dev/hyperapp/hyper-parcel/src/bootstrap.ts:: 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.

Problem description:

Running prettier-eslint I get the error above. Running eslint directly gives no errors and works as expected. I have also tried it with an absolute path to my tsconfig.json, but the error is the same.

Reproduction repository: https://github.com/r0skar/prettier-eslint-test

[r0skar]

I have created a quick test repo: https://github.com/r0skar/prettier-eslint-test

If you open it in VSCode with the prettier extension installed, you will get an error upon saving index.ts, but running yarn eslint will not show any error.

[xinshangshangxin]

when i use .eslintrc.js with

parser: '@typescript-eslint/parser',
plugins: ['@typescript-eslint'],

I directly remove code

  if ([".ts", ".tsx"].includes(fileExtension)) {
    // XXX: It seems babylon is getting a TypeScript plugin.
    // Should that be used instead?
-    formattingOptions.eslint.parser = require.resolve(
-      "typescript-eslint-parser"
-    );
  }

it works fine

[zimme]

I'm looking into this today.

[NewFuture]

update typescript-eslint-parser (Deprecated) to @typescript-eslint/parser

[joefiorini]

Ideally this would be fixed by #197, but it sounds like it's blocked by some necessary changes to the testing infrastructure. In the meantime, would it be possible update this library to use @typescript/eslint-parser instead of the deprecated typescript-eslint-parser? @zimme @r0skar Would you accept a PR for this kind of change or would it run into the same issue as #197?

[OliverJAsh]

The main suggestion here seems to be to update from the old typescript-eslint-parser to the new @typescript-eslint/parser.

However, I would like to make another suggestion: make prettier-eslint respect any predefined TS parsers (via an existing parser option in the ESLint RC).

This way, users may use their own version of the TS parser, in much the same way that prettier-eslint allows users to use their own version of ESLint.

[maxmilton]

It's surprising to me that the user config is mangled.

Wouldn't the optimal solution to this be not to override the user configured parser/s at all? If users want the ability to parse a particular file type they can simply add the parser + relevant overrides. That way they can also add parserOptions correctly.

Keeping the functional scope of the extension tighter would be nice too (less dependencies, etc.).

[zimme]

@MaxMilton It's most likely an oversight when typescript support was added to not keep parser/parserOptions when handling typescript files.

[zyy7259]

I think this issue has been solved by the release of prettier-eslint v9.0.0.

[OliverJAsh]

Confirmed it fixes my issue (https://github.com/prettier/prettier-eslint/issues/207)

[ricardolpd]

could anyone provide an example of a config that provides a work around for this? We are facing this issue with '@typescript-eslint/require-await' in our mono repo.

[mrcnski]

@ricardolpd I was able to fix this by adding "project": ["tsconfig.json"],:

"parserOptions": {
  "ecmaVersion": 2020,
  "project": ["tsconfig.json"] ,
  "sourceType": "module"
},

[vincenzon]

@m-cat that didn't work for me. We are also seeing this trying to add the same require-await rule as @ricardolpd. Are there any other suggestions on how to fix this?

[mikeaustin]

For me, the issue was that the parserOptions.project was not looking in the current project of a mono-repo. I had to specify it as if it was from the top of the repo.

packages/react-desktop/package.json

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ],
    "parserOptions": {
      "project": "./react-desktop/tsconfig.json"
    },
    "rules": {
      "@typescript-eslint/strict-boolean-expressions": "error"
    },

I'm not sure if that is a bug or not. It seems strange the . is the repo root, not the current project root. Now I can avoid those pesky falsyness in conditionals.

The requirement for the "parserOptions.project" property was seen after running npx eslint . --ext .ts

Error: Error while loading rule '@typescript-eslint/strict-boolean-expressions': 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.

[adketuri]

Adding another solution since I found this thread via google. We also had a monorepo and the necessary parserOptions.project property was set correctly. The stack trace pointed to a jest.config.js file it was trying to lint, I explicitly ignored that file in my .eslintrc.js:

ignorePatterns: ["jest.config.js", "node_modules/", "dist/"],