-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Completion details can’t distinguish between a default export and a named export matching the filename #42871
Comments
While you are at it, we probably can send symbol id or something like that which is used to create those extra import etc info. You probably also want to consider caching that information but then you would need to think about what if project changes between the completion and completion entry request and the data results in ambiguity or other error cases related to cache invalidation. |
This proposal sounds good to me and I don't have any concerns about tracking this on the VS Code side and sending it back to the TS Server @andrewbranch Would you continue sending along |
Sounds good to me as well - no concerns tracking this in either of our implementations. |
How long will we need to assume that clients might not return |
@andrewbranch copying this comment from https://github.com/microsoft/TypeScript/pull/42890/files#r580647177 to here Short answer: the de facto policy is "forever" - we don't have a formal versioning or compatibility story for the protocol. Many users decide to stay on older versions of VS for some reason or other, and many users always upgrade to the latest TS, and there's some overlap between the two, so we try to be as compatible as possible. If it becomes a big maintenance burden, it may be reasonable to introduce some breaking changes. Note that I think your question not only applies to the protocol (which has implications for editors), but also to the API as well (which has implications for plugin developers). Which Daniel would have more insight on. |
Bug Report
🔎 Search Terms
auto import default
🕗 Version & Regression Information
This has probably been a bug since auto-imports were invented
💻 Code
🙁 Actual behavior
Two auto-import completions, but both details resolve to the named export.
🖼 GIF demonstrating problem
🙂 Expected behavior
Two auto-import completions that correctly differentiate between the named export and the default export.
Discussion
The reason this happens is that the info we have to go on in
getCompletionDetails
is a really poor starting point for trying to figure out what completion entry we’re talking about. All we have is aname
andsource
, wherename
is the identifier text you want to insert with the completion, andsource
is the symbol name of the module. Notable information we don’t have, because we threw it away at the end ofgetCompletionsAtPosition
, includesThrowing all of this away has two main consequences:
source
. Then we loop through every member/property of its exports seeing if the names we come up with there matchname
.name
is not always the actual name from the exports symbol table;default
andexport=
get converted into a valid identifier for the import, which can be the file name (camel-cased). In the example above, the file name substitution for thedefault
gets “shadowed” by the named export.Fixing this is a near-prerequisite for #31658—it gets extra ugly trying to work around this.
Proposal
Add a new opaquely-typed
data
property (named to match the LSPCompletionItem
field that has the same purpose) toprotocol.CompletionEntry
to replacesource
in what gets sent back to TS Server forgetCompletionDetails
. (To transition, editors can continue to sendsource
as well, and TS Server can continue to use it as a fallback for a while.) Then, TypeScript can add whatever properties we need to that new property./cc @mjbvz @uniqueiniquity any concerns about compatibility issues? @DanielRosenwasser will we need to update any other editors?
The text was updated successfully, but these errors were encountered: