_From @dbaeumer on October 31, 2017 11:29_
Testing: #37177
'vs/base/common/types'import { isStringArray } from 'vs/base/common/types';
However what I want in this case is
import * as Types from 'vs/base/common/types';
and the code should become Types.isStringArray
Would be cool if I can control this via a setting.
_Copied from original issue: Microsoft/vscode#37258_
I think this one needs some thought. For example, what name should we use for * from X?
Maybe this would be better as a refactoring? Change named imports to namespace import. We could also do the other way around.
Otherwise we would double the size of the already enormous completion list.
For example, what name should we use for * from X?
Refactorings conveniently already come with a rename location.
Maybe this would be better as a refactoring?
See #19260
Having that as a separate refactoring makes sense, nevertheless I would like to have this right in the first place and not me picking an entry from a completion list and then being forced to execute another refactorings. In another tool I worked on ( :-) ) we had a configuration comparable to this to control the import generation:
{
module: 'vs/base/common/types',
importType: ImportType.Star,
identifier: 'Types'
}
Default would IMO still be a qualified import.
Default would IMO still be a qualified import.
you mean import *? curious why?
@mhegazy sorry used wrong words. Default should be import { .... } from
Copying my original problem here:
For example, now if I type resolve, VS Code auto suggests millions of resolve from all libraries. This is not helpful:

For me, I usually have this
import * as path from 'path'
path.resolve(...)
However now path. doesn't have any auto import associated with suggestions.
I hope path. can generate completion items that when accepted, add automatic imports to top.
The expected behavior is:
path.@types/node or the Automatic Type Acquisitionpath.resolve, add to top of file import * as path from 'path'I think if one types resolve, auto import import { resolve } from 'path' makes sense. However when one types path.resolve, auto import should do import * as path from 'path'.
In my experience Qualified import makes for more readable code in most cases and its the import pattern advocated for in Haskell, Python, and language-enforced in Go. Likely other language too, I just don't know. Looking forward to support for this. I think its unfortunate qualified is not the default but neither is strict mode etc. so its just another flag to add the many already needed for a solid baseline in TS... not a huge deal I guess. Though its a missed opportunity to nudge the community in a better direction in my honest _personal_ opinion :)
I would be happy if I could write an item name, find it in the completion list, press <SOME_MODIFIER>+Tab/Enter and have it import the thing as qualified. You could pick the name from file/module the item belongs to, with a kebab-/snakecase converted to camelcase. Rename refactoring could be then used on the qualified name if needed.
i.e.
getName completion could become:
import * as User from `some/module/User`
...
User.getName
Most helpful comment
I would be happy if I could write an item name, find it in the completion list, press
<SOME_MODIFIER>+Tab/Enterand have it import the thing as qualified. You could pick the name from file/module the item belongs to, with a kebab-/snakecase converted to camelcase. Rename refactoring could be then used on the qualified name if needed.i.e.
getNamecompletion could become: