Repository navigation
Provide full import statement text from auto-import suggestions #31658
Description
Edit from Daniel Rosenwasser (@DanielRosenwasser)
Given
import { someThi/**/or
import { someThi/**/ }The suggestion is to look for auto-imports to and to fully complete the paths with
import { someThing } from "./some/path"- VSCode Version: Version 1.35.0-insider (1.35.0-insider)
- OS Version: macos 10.14.5
Steps to Reproduce:
- I'm working on a react project. I have a file that does export const Buttons
2.In another file I do import { Button... and I expect auto-complete to display Buttons and hitting enter to complete the path.
But intelliSense just shows the text Buttons (with abc in front of it) and hitting enter doesn't add the path to the import.
If I try to directly import the component from a function - then auto-import correctly adds the Component to the top of the file with an import {Button} from 'correct_path'
Does this issue occur when all extensions are disabled?: Yes
Activity
mjbvz commentedon May 28, 2019
Can you please share some example code or a small example project
Also, when you are typing out the import, is the entire line just
import {without any import path yet?compojoom commentedon May 29, 2019
here I made a gif for you:
I have a something.js - in that file I export the const something
in index.js I try to import { some -> and I was hoping that autocomplete will kick in and complete the line. That doesn't happen.
If I go down and type something -> intellisense suggest something -> I hit it and the import on the top of the file is inserted...
And another funny thing is that - if I use flowjs whenever I define a type and intelliSense suggest it -> instead of importing on the top, the import happens inline? I guess this is another issue, but just wanted to mention it in case it is related.
[-]suggestion doesn't import path[/-][+]Autoimports while typing import[/+]mjbvz commentedon May 29, 2019
This is a feature request. The requested behavior is to support auto imports while typing out the import itself, such as:
Could show a completion for an auto import for
abcwhich would complete the line to:compojoom commentedon May 29, 2019
Ok. That's standard with intelliJ so I expected it with vscode as well. Sorry then.
the completion should be
Since we are talking about import features.
When I try to import get from 'lodash-es' - the generated import is
import {get} from '../../../../lodash-es'
Is there a way for it to be just import {...} from 'node_module' ?
jasonwilliams commentedon Feb 19, 2020
Agree with Daniel Dimitrov (@compojoom)
I was surprised that this didn’t work by design, it’s pretty standard to have import suggestions in other editors, I’ve linked my issue as I raised the same thing in VSCode.
jasonwilliams commentedon Feb 19, 2020
Steps to Reproduce:
test.tsxinto page pages/index.tsxTS Server trace
It does work if i just type it out in the document without being inside of import braces.
Looks like the difference is a
competionInforequest is sent to the typescript server when i type in the document and i get a response with suggestions, but inside ofimporti getTyping inside import
Typing inside document
Ryan Cavanaugh (@RyanCavanaugh) does the above help?
jasonwilliams commentedon Aug 27, 2020
Matt Bierner (@mjbvz) comment above
[-]Autoimports while typing import[/-][+]Provide full import statement text from auto-import suggestions[/+]45 remaining items
DanielRosenwasser commentedon Dec 9, 2020
I think this might be reasonable here too.
andrewbranch commentedon Dec 9, 2020
When auto import completions are not cached, the details request for a single item is usually an order of magnitude faster than the completion list request. Obviously there are huge variables that could affect this relationship, but that’s typical based on old notes of mine. Some portion of the details request is spent redoing work that was done in the completion list request, and the rest is spent on module specifier resolution and building display parts and code actions—so if we tried to do all that work in the completion list request, we’d be able to skip the former part. But let’s still call the details work an order of magnitude faster than the full list work—200ms for the list and 20ms for the details might be a ballpark guess for a small program. This order of magnitude relationship means the total response time for the list request could easily double if we tried to do the details work for 10 auto imports.
My gut feeling is that analysis is coming out overly pessimistic for typical cases, but 10 auto imports is not very many. One of the things that can make module specifier resolution more complicated is symlinks, which play a big role in lerna, yarn workspaces, and pnpm. I don’t want to write a feature that appears miserably slow for power users with big multi-project workspaces, even if it is purely adding functionality where none exists now. I’m open to a smarter filter only if the experience feels really seamless. But part of my hesitation is that this is a non-trivial amount of work that would largely not be reusable if the limitation of not being able to lazily resolve the main edit were removed. Conversely, because normal auto-imports are lazily resolved now, this would be a pretty small feature that could reuse a lot of existing code if that were an option for these kinds of completions. So trying to resolve everything eagerly feels risky, because it’s a decent amount of work and there’s likely to be a performance/experience tradeoff.
jasonwilliams commentedon Feb 10, 2021
I know this issue is already prioritised but I thought it was worth sharing this thread https://twitter.com/markdalgleish/status/1356404787244195840?s=21 showing just how frustrating users find the import intellisense experience at the moment.
bmeck also gathered more here
Just for some anecdotal evidence.
andrewbranch commentedon Mar 2, 2021
What are the reasons someone might want to write an import statement manually, getting good completions, vs. using auto imports as they exist today?
andrewbranch commentedon Mar 11, 2021
Matt Bierner (@mjbvz) Johannes Rieken (@jrieken) this feature is getting close, but here’s the next UX hiccup in practice: the existence of the
import statementsnippet completion blocks new completions from being requested once you start typing the identifier you want to import, for as long as the characters you type are an ordered subset of “statement.” (I forgot to turn on screencast mode in this GIF, but to finally get completions, I press Esc and then Ctrl+Space.)I could change the snippet prefix to just “import,” but that would give it the same label as the plain keyword completion for
import, provided from TS Server. Alternatively, could we find a way to not block a new completions request in this case? It’s blocking because continuing to type is simply filtering down the list that was returned when typing theimportkeyword, and it usually does make sense not to request new completions when an existing item is still a match. But I think snippets that include a space in their prefix kind of break that logic.jrieken commentedon Mar 12, 2021
The
vscode.CompletionListhas theisIncompleteproperty for that. This means that we will ask for new completions, for that provider, after each keystroke.andrewbranch commentedon Mar 12, 2021
Johannes Rieken (@jrieken) how would that work in this example? From
itoimpor, it looks like we should just be offering normal global completions. It’s only once the user has gotten toimport(with trailing space) that we want to start offering import statement completions, but because of the snippet, we never get a chance to tell VS Code that the list is incomplete, unless we said it was incomplete from the very beginning.jrieken commentedon Mar 12, 2021
That. Also note that we only re-request completions from those providers that signaled incomplete-ness. So, you want to split this up into a provider that is complete and one which isn't. The trigger context will also tell you if you are being ask to complete an incomplete result (which again can be another incomplete result)
andrewbranch commentedon Mar 12, 2021
That would be a huge architectural change that is not worth this feature in the slightest, especially considering the feature is not just for VS Code. There is only one (semantic) TS Server, and it’s currently leveraged by one VS Code completion provider—I think changing that is off the table for now, because it would create a ton of non-backward-compatible work for every other language server client.
andrewbranch commentedon Mar 13, 2021
For now I’ve managed to use a combination of
isIncompleteand conditional triggering on a space character from the typescript-language-features completions provider. I wish theimport statementsnippet completion remained intact, but I guess with the additional trigger, it goes away, and the snippet completion is not re-triggered with a space character:Users who don’t want that behavior can disable import statement completions with a preference, and it will avoid retriggering on that space.