TSServer Completions - Context Needed

Search Terms

• completions
• tsserver
• completionsInfo
• completionEntryDetails

Suggestion

I know this may need to go through the lengthy process of going through lsp spec then implementation etc etc but figured I would bring it up here first in case I am missing something.

I was recently working on improvements to the vscode handling of linking in the documentation hovers and completions to support relative linking (from the defined documentation: @see https://github.com/microsoft/vscode/pull/98238 ) among other things.

For the most part, this entailed supplementing the requests being made with a request for the definition so that I could get the path of the file that actually is providing a given documentation value.

This worked fine for hovers and even completions in SOME cases but in others it was impossible to reliably capture the definition information - namely during completions.

It seems like it makes sense that we would want to be able to know where the information being provided is actually coming from. This would allow quite a few improvements to the UX of the editor to give even richer information.

For example, a completion popup could provide information & potentially doocumentation of the actual enclosing type, file, and linking using the new features added in the PR given.

Currently when I can not get the path I just have to render as regular text which provides an inconsistent user experience (and actually breaks things in current vscode releases).

With vscode, say you have imported a value and you are building an object that implements the imported type:

import type { ButtonProps } from 'components/Button'

const props: ButtonProps = {
   | <--- cursor is here
}

Now the user opens the completions context or starts typing. The problem is that we can capture the completionsInfo and everything else, but based on the current cursor position it is impossible to actually know what actually is providing the type itself.

You will notice that the right side of the popup is actually blank here as well due to this. Ideally we could render the name of the type there and potentially in the actual hover allow the user to get the documentation of the ButtonProps itself.

Examples

Essentially either allow providing of an argument to completionEntryDetails and/or completionsInfo to return the location of the type providing the definition so that a call to definition or quickInfo could be made to capture more context if desired, or just provide that by default.

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.

Beginne damit, die in der Issue genannten tsserver-Completion-APIs zu prüfen: completionsInfo und completionEntryDetails sowie definition und quickInfo. Vergleiche das Verhalten für das ButtonProps-Beispiel und den verknüpften VSCode-Integrationskontext. Als abgeschlossen sollte eine klare Möglichkeit definiert sein, wie Completion-Ergebnisse den bereitstellenden Typ oder Quellort offenlegen, wobei die daraus resultierende Dokumentation und das Verknüpfungsverhalten verifiziert werden.