Request (probably long-term) type compilation debugger

[krryan]

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:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[inoyakaigor]

I hope this issue will get maximum priority. We, the developers, really need it. Especially non-experienced ones

[aspirisen]

Hope one day we will be able to debug TypeScript types.

Nowadays ts has a lot of useful features like conditional types, mapped types, template literal types etc.. However, the types sometimes are hard to understand (for examples types from type-fest are super complex). TS now have so to say "regexp" problem - write once, forget forever. Once you finished with your complex types it will be hard for someone to easily understand what is going on inside those tricky-recursive-conditional-mapped types.

[quixot1c]

Would be very much appreciated for recursive conditional type debugging.

[m93a]

Yes, we definitely need more than the current error messages. It is nearly impossible (sometimes completely impossible) to figure out what the type checker wants – even with an extension like Pretty TypeScript Errors which makes the types much more readable.