TS auto import should support configuring whether a star or a qualified import is used.

Dirk Bäumer (@dbaeumer)

From Dirk Bäumer (@dbaeumer) on October 31, 2017 11:29

Testing: #37177

vscode source code opened in VS Code
open a file that doesn't import 'vs/base/common/types'
type isStringArray
select the entry from code complete list
the following import is inserted:

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?

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?

Mohamed Hegazy (@mhegazy)

Mohamed Hegazy (@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:

Type path.
VS Code should auto complete, based on either type definition at @types/node or the Automatic Type Acquisition
When user accepts path.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 :)

Related: #23830

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

I think this one needs some thought. For example, what name should we use for * from X?

Consider https://jsdoc.app/tags-module.html. We can define the @module tags in the single file or the index.ts under the directory, and then, it should be warned if there are multiple different @module under a directory with index.ts

Anyone know of an extension that can do this right now?

wildeyes

wildeyes You might find this useful: https://github.com/unsplash/ts-namespace-import-plugin

Navigation Menu

Repository navigation

TS auto import should support configuring whether a star or a qualified import is used. #19630

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TS auto import should support configuring whether a star or a qualified import is used. #19630

Description

Activity

mjbvz commented on Nov 1, 2017

DanielRosenwasser commented on Nov 1, 2017

dbaeumer commented on Nov 1, 2017

mhegazy commented on Nov 1, 2017

dbaeumer commented on Nov 3, 2017

octref commented on May 11, 2018

jasonkuhrt commented on Jun 20, 2018

OliverJAsh commented on Aug 8, 2019

katis commented on Nov 12, 2019

JuoCode commented on Mar 9, 2023

wildeyes commented on May 23, 2023

OliverJAsh commented on May 24, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions