Auto Import not working with node_modules

[KirillMetrik]

• VSCode Version: 1.31.0
• OS Version: Windows 10

Steps to Reproduce:

1. Unpack the attached source test-app.zip
2. run npm install
3. Open app.module.ts file
4. Remove NgModule import (the @NgModule will be highlighted with an error)
5. Place cursor on the @NgModule. Here expected behavior is that the light bulb would appear and suggest to add missing import. In reality nothing happens. I am still able to add import manually but it's impossible to use auto import feature for this. When entering import manually Intellisense works without any problems.

This might seem like a minor problem but the example is just a small extract from a big project. It seems that VSCode (or TS server) is not checking for possible typings in node_modules. In the end we have to add imports manually everywhere which is very time consuming and simply kills productivity.

Does this issue occur when all extensions are disabled?: Yes

[mjbvz]

I confirmed this with [email protected]

There do not appear to be any errors in the ts server logs. Once you add any @angular/core import to the file, then we do properly suggest the import quick fix

[RyanCavanaugh]

This is an intentional performance/helpfulness trade-off.

We don't eagerly consume all .d.ts files from node_modules - doing so would be prohibitively expensive in a world where there are regularly possible thousands of definition files in node_modules.

When the Angular .d.ts file isn't consumed, we have no way of knowing that NgModule happens to come from @angular/core, thus can't suggest that auto-import.

[christianbradley]

I have this issue as well, and I'm confused as to why it was closed without further discussion. Is there any workaround you can suggest? For example, I'm using the wonderful fp-ts library by gcanti, and I'm constantly having to type out every import - I don't remember this happening before v3.x.

[RyanCavanaugh]

it was closed without further discussion

I literally explained why it works the way it does, then you commented, now I'm responding. Not sure how that's "without further discussion" ? 😕

I have this issue as well ... I'm constantly having to type out every import

It sounds like you're having a different issue. Once you have the first import, subsequent imports to the same library should be available for automatic importing. Can you (in a new report) outline the steps to reproduce the problem you're describing?

[KirillMetrik]

I am experiencing the same problem as @christianbradley describes. Unfortunately I wasn't able to create a 100% reproduction case, so decided not to post it.

[christianbradley]

@RyanCavanaugh - by "it was closed without further discussion" I'm just referring to the fact that the feature was set to "closed" - without further discussion.

With a library like fp-ts - everything is pulled from lib, ie:

import { Option, fromNullable } from 'fp-ts/lib/Option'

It does look like once I import from that file, anything exported from that file seems to generally be available for auto-import. However, if I start typing out another export from that library, say, scanRight from fp-ts/lib/Array, it doesn't suggest the import, and quick fix doesn't show it either.

Oddly, some exports from other modules are suggested - I'm assuming this is because are referenced by Array.d.ts in some manner. ie: fp-ts/lib/Either

If there was a way to inform the compiler to eager-load everything from a specific folder, module, etc, that would be wonderful.

As a side question - was this always how the compiler worked? I feel like this has only happened recently, but I could be wrong.

[unional]

@RyanCavanaugh is it possible to read only those specified in package.json and go down transitively?

[Domiii]

Any progress on this?
It almost looks like the team has largely deprioritized this issue?

I am also strongly in favor of @unional's suggestion, same as suggested here.

[dotdevio]

+1

[andrewbranch]

Just for clarity of record keeping, #36042 tracks the reconsideration of this issue.

[Toliak]

Non working auto import suggestions for packages in node_modules confirmed for me in react blank project (yarn create react-app vscode-issue-30033 --template typescript)

Environment
OS Version: Linux manjaro 5.4.97-1-MANJARO
Code Version:

1.53.1
5d424b828ada08e1eb9f95d6cb41120234ef57c7
x64

TypeScript Version: 4.2.3
All extensions are disabled.

Variant 1
[email protected] package.

Type somewhere concatMap. Expected: suggestion import { concatMap } from 'rxjs/operators';

Actual: no suggestions...

Variant 2
[email protected] package.

Type somewhere loadTypeScript. Expected suggestion import {loadTypeScript} from 'ttypescript/lib/loadTypescript';

Actual: nothing..

Variant 3
[email protected] package.

Type somewhere bindKey. Expected suggestion: import {bindKey} from 'mtasa-lua-types/types/mtasa/client/function/input';

Actual: no suggestions again

What about another IDE?

I am frustrated when I see that behavior in VSCode. In WebStorm, for example, all variants works perfectly.

[andrewbranch]

@Toliak those don’t work because those modules aren’t referenced from the package root. When we see your package.json has "rxjs" in it, for example, we look at rxjs’s package.json for the file listed by types, and load that. We also load everything it imports/references, and those things become available for auto import. What we don’t do is a recursive directory search, looking for other typings files. That would be extremely expensive. It’s an unfortunate limitation, but it is expected behavior for now.

[dotdevio]

@Toliak those don’t work because those modules aren’t referenced from the package root. When we see your package.json has "rxjs" in it, for example, we look at rxjs’s package.json for the file listed by types, and load that. We also load everything it imports/references, and those things become available for auto import. What we don’t do is a recursive directory search, looking for other typings files. That would be extremely expensive. It’s an unfortunate limitation, but it is expected behavior for now.

Why there cant be node_modules+1 recursive lookup not node_modules+n recursive and this can be adjusted via config? So all node_modules root packages are available via auto suggest??? not only packages listed in package.json. This is really annoying.

I mean:

package.json:

"some_package": "*",

node_modules:
some_package/
some_other_package/
  node_modules/
    some_dependency/

so some_package and some_other_package now will be available for autocomplete, but not some_dependency?

I think its very often to install some package which has dependencies which we will use in project but they cant be auto-suggested until added into root package.json but i dont want to specify them only for vscode autosuggest because its an approach to have package which installs needed deps in project.

[RyanCavanaugh]

Why there cant be node_modules+1 recursive lookup not node_modules+n recursive and this can be adjusted via config?

We're not super interested to spend complexity or performance budget here. There are many more impactful issues to address first. You can write an import, once, to get the module into your program, after which point auto-import will see them.