Repository navigation
Auto-importing modules as namespaces? #23830
Description
I’m not sure what the best way is to fix this, but: auto-importing is incredibly helpful. Alas, it only works for named exports. However, imports such as the following are frequent in Node.js and there, you get no help:
import * as path from 'path';Possible solution: offer an auto-import if:
- there is an unknown
foofollowed by a dot and foois the base name of a module.
Activity
RyanCavanaugh commentedon May 2, 2018
Can you clarify what you're typing and when you'd expect this to show up?
rauschma commentedon May 2, 2018
path.(pathbeing an unknown identifier).'path'.But I’m open to anything that helps with
import * as: maybe there doesn’t have to be a dot afterpath. Then auto-importing would be offered for both namespace imports and named imports.rauschma commentedon May 2, 2018
I don’t think that that would be useful:
path, both named imports and namespace imports are common.path”. Therefore, I’d prefer it if an IDE would namespace-importpathfor me when I first mention its name.mhegazy commentedon May 3, 2018
So the suggestion here is to offer the names of modules in the completion list with an additional action to import them? i.e.
pathwould show up as a completion entry in the global scope.rauschma commentedon May 3, 2018
Yes! But I’m not sure what you mean by “in the global scope”.
pathwould be global-ish, but the suggestion would appear anywhere, independent of scope.rauschma commentedon May 3, 2018
Oh, and it could be complemented by a quick fix offering to namespace-import
pathwhenever that identifier is ever unknown anywhere.mhegazy commentedon May 3, 2018
My only worry is the amount of unrelated names we put in the completion list.
DanielRosenwasser commentedon May 4, 2018
True, but we already add in every possible named export in a project context.
30 remaining items
andrewbranch commentedon Feb 8, 2022
I’ve looked into this a good bit and decided I don’t want to do it in general. We can’t know the conventions by which the namespace export is named:
pathcomes from"path"butReactcomes from"react". It would be super annoying when we inevitably get a convention wrong.I investigated this:
The
"path"module typings declare anexport = pathand we pull the name from the declaration of the symbol being exported. On the other hand, the"url"module (along with the majority of node built-ins) has noexport =declaration; it’s simply a collection of named exports. These named exports could be wrapped in a namespace namedurland thenexport = urlfrom the top level. The module would behave almost identically to the way it behaves as written today, except thatexport * from "url"would become an error. It’s worth noting that some of the node built-ins likepathandassertare written as anexport =out of necessity or convenience, andexport * from "path"is already an error because of that, despite it being valid in Node. It could be worth making the change to the rest of the modules to allow auto-imports to work better. This is a question for the Node typings maintainers to consider on DefinitelyTyped.Oliver Joseph Ash (@OliverJAsh)’s suggestion of picking up on namespace import names used elsewhere in the program is probably the only solution here that can provide a decent UX, but I think it’s too much complexity for the value it delivers. (It would be too expensive to look up these associations from other files on demand when we’re generating a completions list, so we’d have to introduce a new cache, which means you have to think about cache invalidation.)
As far as I know, these APIs are separate, but there is nothing stopping a single extension from sharing code to contribute to both APIs.