Request (probably long-term) type compilation debugger

Search Terms

debug type, debug types, debug compilation

Related

• #3318 about debugging the compiler; with enough knowledge of tsc it probably could be used for this but that’s quite a barrier
• #29937 about logging types and other strings during compilation

Suggestion

This is probably a huge amount of work, but as Typescript’s type system becomes more and more expressive and complex, it also becomes harder to reason about and know why things are not doing what you want (or, sometimes, why they are doing what you want). For more complex type expressions, there is a lot of trial and error, and even when you get it working it can be a complete mystery why it’s now working.

For runtime issues, we have a solution to that: the debugger. For compile-time issues, we’re stuck instead with trying to break up our code into separate types to see the result at each step—and even that isn’t completely effective, because being a separate alias rather than just in-lined code can actually change behavior!

Obviously, this would be a huge effort. I certainly don’t expect anything like it any time soon. But as a long-term goal, I think it’s only going to become more and more necessary. Already we have cases where Typescript doesn’t reason about types as completely as it could explicitly because we lack a debugger to track it down—see Ryan’s comment here where { type: "foo"; } & { type: "bar"; } is not narrowed to never because of concerns about some conflict deep in the object tree causing the entire type to resolve to an opaque never with no way of figuring out why.

So this is kind of a question/suggestion: is this something the TS team is interested in/would like to do “someday,” and if not, I’m suggesting it should be.

Use Cases

Any complex type.

Examples

I don’t have specific suggestions for what the debugging would look like. Stepping through a type evaluation in VS Code would be awesome (it has a debugger already for running the code, obviously), but really anything that exposes more of what’s going on so we can make more informed choices about our types would be good.

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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

The issue identifies no implementation files, tests, or entry points. Start by reviewing the related compiler-debugging issue #3318 and type-logging issue #29937; the work is complete only when a defined way to inspect or step through type evaluation has been designed and implemented.