API request: allow ignoring ts-(expect-error|ignore) in getPreEmitDiagnostics

[JoshuaKGoldberg]

Suggestion

🔍 Search Terms

ignore comment directives ts-expect-error ts-ignore

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

API consumers such as typescript-eslint would benefit from being able to get the diagnostics in a file that would be emitted were it not for a // @ts-expect-error or // @ts-ignore. Can we add in an options parameter to program.getPreEmitDiagnostics to allow consumers to stop those comment directives from suppressing errors?

I threw together a rough draft of how this could look in the TypeScript source here: JoshuaKGoldberg/TypeScript@a7c07ff...JoshuaKGoldberg:TypeScript:get-diagnostics-options. Just in case it's helpful.

📃 Motivating Example

JoshuaKGoldberg/eslint-plugin-expect-type#65: we'd like to make lint rules that assert on the error message matching what's expected, as a userland solution to #19139 not being accepted.

💻 Use Cases

Here's how we could change what eslint-plugin-expect-type does today:

- const diagnostics = ts.getPreEmitDiagnostics(program, sourceFile);
+ const diagnostics = ts.getPreEmitDiagnostics(program, sourceFile, { skipCommentDirectiveErrorSuppressions: true });

Without this API, users either:

• Can't both suppress type errors and lint that the suppressions match up with TypeScript
• Need to have lint rules & similar rewrite files to remove the comments - essentially parsing & type checking them twice

[RyanCavanaugh]

We try to keep our API surface pretty minimal. Since it's an API call, you can transform the source text (replace ts-ignore with ts-zzzzzz) before handing it over to get equivalent results. Thoughts?

[JoshuaKGoldberg]

No juice 😞. We need to be able to get the original text in case of anything that transforms text. For example, ESLint rule complaints can have fixers that move entire functions / other chunks of code. Fixers have no way of knowing that the user has configured @typescript-eslint/parser -> @typescript-eslint/estree with some setting like { rewriteDirectives: true }.

[fatcerberus]

Rewriting the comments also has the concerns about duplicated parsing work mentioned in the OP (unless it's just a dumb text-based find/replace but that feels problematic).