Giving an error type to types that have failed to resolve, instead of any

🔍 Search Terms

Types that fail to import should not be typed as any. SkipLibCheck. Type resolution failure.

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Currently if TS fails to resolve a type, for example because it can't resolve an import, the type is set as any. TS will display the type by it's alias (the local name given to the type), hiding that fact that it is any underneath. any being a special type that largely disables type checking, being silently introduced, can hide code errors.

Failing imports are typically reported by TS as an error, even if using that any typed type later on doesn't produce an error. However if there is a type resolution failure within an external module with skipLibCheck turned on (which is widely used and recommended, for multiple reasons), then there is no error and an any type is silently introduced to the project types.

The suggested solution is instead type these types with an error type, working name: failed. An assignment to or from a failed type is an error, like an opposite to any.

--

I've ticked non-breaking, even though it could lead to compilation of existing code failing, because it would only be highlighting an error that previously wasn't highlighted. It's non-breaking in valid code.

There would be a degree of annoyance never-the-less in triggering compilation errors in code that previously compiled, caused by problems in external libraries. Error messages indicating where the type resolution failed would be very helpful here.

I'm putting this out for discussion, because it's difficult for me to foresee the full consequences and challenges of such a change.

📃 Motivating Example

In this simple Playground we import a type from a package with an internal resolution error, that leads a type X['c'] to be any. TS reports no errors to us and lets us perform type-irrational operations.

💻 Use Cases

Fairly obviously, it's a safeguard against mistakes in external libraries, and it would also make broken imports more obvious by showing errors at the use site not just at the import site.

This occurred to me when dealing with a typing issue in @stripe/stripe-js (1.3M weekly downloads) stripe-js#714. Just fixing the import in the index file as the maintainer suggested would have introduced this issue to that library.

Comienza con el ejemplo vinculado de Playground y con el análisis de la propuesta sobre las importaciones fallidas, los módulos externos y skipLibCheck. Investiga cómo los tipos no resueltos se convierten actualmente en any y determina el comportamiento y los diagnósticos previstos para un tipo fallido propuesto. El trabajo se consideraría terminado cuando exista un diseño acordado que gestione el ejemplo motivador sin debilitar silenciosamente la comprobación de tipos.