Skip to content

compiler option to fallback to unknown instead of any when failing to resolve a type #46330

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
5 tasks done
DetachHead opened this issue Oct 12, 2021 · 1 comment
Open
5 tasks done
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@DetachHead
Copy link
Contributor

DetachHead commented Oct 12, 2021

Suggestion

πŸ” Search Terms

unknown instead of any 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

currently, when a type fails to resolve, there's an error in an external lib suppressed by skipLibCheck, or an error suppressed by @ts-expect-error/@ts-ignore, the type falls back to any

it would be nice if there was a compiler option that changes this behavior to unknown instead of any. it would make this feature even more useful too

πŸ“ƒ Motivating Example

currently, @ts-ignore and @ts-expect-error comments aren't exposed in .d.ts files. one of the concerns with changing this functionality seems to be that it can result in any leaking into the codebase (see #38628 (comment)).

πŸ’» Use Cases

  • makes it safer to use skipLibCheck, for example if a lib was compiled using a different version of typescript which causes errors on the version you're using
  • makes it a little bit safer to use @ts-expect-error
@andrewbranch andrewbranch added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Nov 4, 2021
@Silic0nS0ldier
Copy link

Type errors in libraries with unchecked types isn't the only place any can sneak in. If resolution is aborted (e.g. long lookup chain or bail-out triggered by a heuristic) any ends up being used instead. I've observed this happening on 2 occasions in the Canva source and wouldn't be surprised if more instances are hiding away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

3 participants