Allow specifying diagnostic code in ts-expect-error

Suggestion

🔍 Search Terms

ts-expect-error

✅ 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

Allow @ts-expect-error to specify diagnostic codes to be more precise in expectations. Example: // @ts-expect-error TS1234

Will only expect that diagnostic code. If the same line triggers a different diagnostic code, the expectation will error as if there was no error on the proceeding line.

📃 Motivating Example

This feature will be particularly useful when migrating code (1) between repositories with different TS configs, or even for (2) a slightly safer path when upgrading TS versions if all issues are not immediately fixed.

💻 Use Cases

The Teams Org is facing a code migration that I expect will benefit from this greatly. Please reach out to me (or I will come to office hours) and we can go through that example.

Code

I have attached a PR which implements the change as an example. Let me know what you think!

[IllusionMH]

Related discussion about specific codes: #19139 (I think there were similar topics about @ts-expect-error)

While I agree that it would be great to have more precise checks for errors - I think that proposals should address couple of concerns:

1. error code after space might be common in existing code, how to avoid breaking them?
2. error codes aren’t stable in TS and https://github.com/microsoft/TypeScript/issues/19139#issuecomment-641402113 (may require to open collapsed comments) should be also addressed in new proposals.

[markjm]

It is perhaps also worth noting that one of the reasonings for not supporting this functionality is to not support backwards integrations as errorCodes change, but VSCode TS extension uses these codes for a similar purpose.

https://github.com/microsoft/vscode/blob/99908438228fd427b33b45e8074195ccc312a020/extensions/typescript-language-features/src/utils/errorCodes.ts