Is a project fully type-checked when using @typescript-eslint/parser?

[ehaynes99]

I have a project where my build is doing 3 things

• linting with eslint - this uses @typescript-eslint/parser and includes several rules requiring type checking
• type checks the project using tsc with noEmit
• builds with swc

I recently started wondering if the second step is redundant. Linting will emit errors if there is invalid TypeScript. Assuming that my lint task covers all files included in the tsconfig, is it safe to assume that everything would be type checked during linting, eliminating the need for a distinct check?

[JoshuaKGoldberg]

No, rules that require type checking just read information from the TypeScript API. They don't ask for type errors or report any type errors from TypeScript.

https://typescript-eslint.io/linting/troubleshooting#why-dont-i-see-typescript-errors-in-my-eslint-output

You can check this for yourself by adding clear type errors (e.g. const value: number = "gotcha!";) in a .ts file and seeing if lint rules re-report TypeScript's error messages. They won't.

I appreciate your openness in asking in a discussion - but please next time read the FAQs and try it out for yourself.

[ehaynes99]

Apologies. I does emit parsing errors for e.g. const value: number =; which I incorrectly assumed were coming from tsc.

FWIW, all of the links that look relevant in a search for "type checking" are broken...

• https://typescript-eslint.io/docs/development/custom-rules/#type-checking
• https://typescript-eslint.io/docs/linting/configs/#recommended-requiring-type-checking
• https://typescript-eslint.io/docs/linting/configs/#built-in-configurations
• https://typescript-eslint.io/docs/linting/typed-linting/
  

[JoshuaKGoldberg]

Ah sorry about that! #6805 -> #6817 should be released on Monday.

[armano2]

hmm, that's actually not true Josh, fix that i did solves only server side redirects and its already live, search index is broken but its not related issue