TSServer Completions - Context Needed

[bradennapier]

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 microsoft/vscode#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.

[RyanCavanaugh]

@mjbvz do you have any additional context to help us prioritize this?

[mjbvz]

I believe this is trying to address the same core problem as #35524

[bradennapier]

Kind of, but this is definitely different. This is about resolving the path and/or information about the type that is being given information about in completions.

I was able to fix relative linking in most areas with the PR provided and linked, but there were cases where I couldn’t simply due to the language server not able to provider any information about the type it is providing information about.

If I am getting completion info for the type MyType, it doesn’t give me anything - I don’t know the name MyType, I don’t know the path to the file that defines MyType, nothing.

I feel any time information about a type is given perhaps an id should be given which can be used to request further information about the type that provides it? Something along those lines .

@mjbvz i also think we should discuss reconsidering my PR. If I take the project/workspace protocol part away (which is still think is good to have), it does have solutions to the comment you linked as well as fixes to bugs that exist in vscode to this day (such as relative links and properly rendering links in hovers)