Interactive Diagnostics

[weswigham]

One of the larger complaints about TS that we hear is that the error messages can become rather long. We go to great lengths to improve this were we can - re-targeting errors to more specific spans, trimming the fat from specific error messages, providing quick fixes where possible, and more - but at times, an error message is simply deep, and it has good justification for being so - because, for example, some types aren't related in a complicated way. For a little while I've been wondering if it'd be useful to also attack this from the other side - to provide more tools for inspecting to what an error is referring and inspecting what the compiler knows about the participants in the diagnostic. To that end, I think making IDE features like Go To Definition and Find All References able to operate directly on the contents of an error message would be hugely useful. It removes one or sometimes many steps in the debugging process - no longer would you need to find where the type in the error came from and dive into it there, instead you could jump right into it from the error, at any level of error complexity.

This is a draft PR with the current draft of the TS side for my proposal (mostly for my own tracking) for more interactive diagnostics in the editor. In vscode, in its current state, this looks roughly like this:

My own TODO list of things I think are needed:

• Refactor API to return structured spans of diagnostics-with-symbol-data instead of a markdown string directly (and handle conversion to markdown in the vscode typescript extension)
• In the vscode side, put the definition links into the quickinfo hover as well, but have it pin into the peek error dialog upon interaction
• In addition to definitions, provide additional data to populate a full right-click context menu for, eg, find all references
• Provide an additional endpoint for expanding ... references (both truncated content and reverse mapped types)

[typescript-bot]

Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping @sheetalkamat, @amcasey, @mjbvz, @minestarks for you. Feel free to loop in other consumers/maintainers if necessary

[weswigham]

@typescript-bot juuuuuuust a little premature. A bit.

[orta]

This is great! Ideally those type names would just always be clickable in the first popover too. ❤️

[weswigham]

@typescript-bot pack this

[typescript-bot]

Heya @weswigham, I've started to run the tarball bundle task on this PR at 93756d5. You can monitor the build here. It should now contribute to this PR's status checks.

[Kinrany]

Currently type resolution has some hacks intended to make error messages more readable, like "foo" & "bar" not being reduced to never.

Would this PR help with that? In the example above ideally the type would be never, but the IDE would be capable of expanding never back to "foo" & "bar" when the user clicks/hovers the "never" word in the error message.

[SephReed]

What's the status on this? I have a tool that is yielding in-actionably complex errors over trivial misspellings.

[yaquawa]

Same question as above, I really need this‼

[sandersn]

To help with PR housekeeping, I'm going to close this draft PR. It's pretty old.

[evelant]

@sandersn @weswigham @RyanCavanaugh AFAIK this is the only place this issue is being tracked and it looks like significant work went into the draft implementation. Just because it hasn't had any attention in awhile doesn't make it invalid IMO.

This is an important feature especially when working with libraries that generate large inferred types (such as mobx-state-tree). Without this functionality it can be impossible to see useful error output because it always gets truncated. Could you please reopen this? How might we move this forward? I think it's a very valuable feature.

[weswigham]

Honestly, what this needs is some insights on the UI in the editor - as-is with the vscode branch we set up, we ran some tests with users and it seemed like nobody expected anything in a hover to be interactable/linkified (nobody was able to discover the feature without being told about it), making the feature about as good as nonexistent. We didn't iterate on it too much after that - it's possible there's a ui design that actually makes this discoverable, though, which'd make it worth pursuing again.

[SephReed]

The devs you're testing don't sound like the kind that are responsible for solving big problems. I get that juniors out-number seniors a million-to-one, but the upper limits of tech are based off the issues that advanced users face. It's silly to make this a popularity contest.