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

Created on 11 Feb 2019  路  11Comments  路  Source: prettier/prettier-eslint

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

Most helpful comment

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.

All 11 comments

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.

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

I'm looking into this today.

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

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?

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.

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.).

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

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

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

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Vadorequest picture Vadorequest  路  7Comments

kripod picture kripod  路  5Comments

tim0991 picture tim0991  路  4Comments

m-diiorio picture m-diiorio  路  6Comments

chrisbobbe picture chrisbobbe  路  8Comments