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 @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.