ban usages of @ts-expect-error and @ts-ignore in places that would get stripped when emitting .d.ts files

[DetachHead]

Suggestion

🔍 Search Terms

ts-ignore ts-expect-error d.ts

✅ 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

@ts-ignore and @ts-expect-error comments that end up exposed in .d.ts files are stripped when compiled, which results in downstream errors that can go undetected until someone tries to use your package. see #38628 (comment)

it would be nice to have an option to ban the comments in type definitions and signatures, where they'd need to be exposed in the .d.ts files.

[andrewbranch]

I wonder if type checking your own .d.ts emit would be a workable alternative? This suggestion makes sense but I don’t think we have a great detection mechanism for it in place.

[DetachHead]

it's difficult because i often have to turn on skipLibCheck due to issues in node_modules that are outside of my control. is there a way to turn that compiler option off only for files that are part of my project?

[andrewbranch]

No, but I think there might be a previous issue for that too 😆