No import suggestions for transitive dependencies in [v3.7.3]

[gdostie]

TypeScript Version: 3.7.3

Search Terms: auto-import suggestions transitive dependencies

Description of the issue

Auto-import suggestions for transitive dependencies exported types don't show up anymore.

• In version 3.6.4 it works fine.
• If you delete package.json the suggestions start showing-up
• Tried in vscode and webstorm and the same behavior happens in both

Code

// package Z
const Crab = "🦀";

export function logCrab() {
 console.log(Crab);
}

export function logCrab2() {
 console.log(Crab);
 console.log(Crab);
}

// package Y (depends on Z)
import { logCrab, logCrab2 } from "demo-imports-issue-dep-dep";

const Pineapple = "🍍";

export function logPineapple() {
 logCrab();
 console.log(Pineapple);
}

export function logPineapple2() {
 logCrab2();
 console.log(Pineapple);
 console.log(Pineapple);
}

// package X (depends on Y)
import { logPineapple } from "demo-imports-issue-dep";
import { logCrab } from "demo-imports-issue-dep-dep";

logPineapple();
logCrab();
// log <-- type this and hit the shortcut to have suggestions

Expected behavior:
v3.6.4 (notice logCrab2 is in the suggestions)

Actual behavior:
v3.7.3 with package.json (notice logCrab2 isn't in the suggestions):

v3.7.3 without package.json (notice logCrab2 is in the suggestions)

Playground Link:

Base project example: https://github.com/gdostie/demo-imports-issue
Project's direct dependency: https://github.com/gdostie/demo-imports-issue-dep
Project's transitive dependency (which exports the logCrab2 function): https://github.com/gdostie/demo-imports-issue-dep-dep

Related Issues:

[AviVahl]

this was done on purpose AFAIK: #32517

[gdostie]

Hi Avi Vahl (@AviVahl) thanks for the input.

In my team's particular setup, the annoyance caused by that change far outweighs the performance gains brought by it.

Basically our setup looks like the following:

• We have a common package that shares common code between 8 other packages.
• We moved a bunch of common dependencies in the common package so that their versions is always the same across the 8 other packages which prevents us from having to do 8 PRs when we need to bump a dependency's version. Maybe we should be using a mono-repo at this point, but we are currently not.

Solutions ideas/suggestions:

• Add an entry in the compilerOptions to disable the new optimization behavior at will.
• Allow auto importing things from a transitive dependency X only if there is already something imported (manually) from X. I don't know if makes sense or not, I'm just shooting ideas.
• My team should changes its whole setup to retrieve a behavior that was previously working fine.

[fatcerberus]

Relevant xkcd: https://xkcd.com/1172/

Sorry, I couldn't resist. 🚎

[RyanCavanaugh]

We have to take some performance and usability trade-offs in auto-import to make it a useful feature that doesn't bog down the entire development experience.

From an npm perspective, a package's dependencies are not part of its external contract, and assuming that a transitive dependency that's here today will be there tomorrow is a fundamentally incorrect assumption. Of course in this case you control the primary dependency and can enforce that constraint, but from a technical perspective, us culling the transitive dependencies here is objectively correct.