Package dependencies and The inferred type of ... cannot be named without a reference to ...

[AnyhowStep]

TypeScript Version: 3.3.0-dev.20190119

Search Terms: inferred type, cannot be named, reference, package, dependency

This isn't really a traditional bug report. Mostly a PSA of some sort.

Code

The dependencies of interest are,

• My project has a direct dependency to "A"
• My project has a direct dependency to "B"
• "A" has a direct dependency to "B"

Before updating,

• My project has 1.0.0 of package "A" (older version)
• My project has 2.51.1 of package "B" (older version)
• 1.0.0 of package "A" has 2.51.1 of package "B" (older version)

After updating package "A",

• My project has 1.0.1 of package "A" (newer patch version, bug-fix, no .d.ts changes)
• My project has 2.51.1 of package "B" (older version)
• 1.0.1 of package "A" has 2.51.2 of package "B" (newer patch version, bug-fix, no .d.ts changes)

There's a package version mismatch here.
My project has 2.51.1 of "B" but the package I updated has 2.51.2 of "B".

---

In the newer version of "A" and "B", no .d.ts files were added/removed/modified.

---

Expected

Before updating, the project compiled.
So, the rationale is that after updating a patch version, the project should still compile.

Actual

After updating, the project stopped compiling.

tsc crashed; out-of-memory exception.

VS Code gave me the error,

The inferred type of ... cannot be named without a reference to node_modules/A/node_modules/B

---

Workaround

The workaround is to just update "B" to 2.51.2 in my project. After doing so, everything compiles again.

It seems like package versions matter to TypeScript when it comes to transitive dependencies. Even if it's a patch version and no .d.ts files are added/removed/modified.

Related Issues: #29221

[RyanCavanaugh]

It'd be great to have a concrete way to repro the OOM exception

[simonfox]

@RyanCavanaugh we are bumping into this issue in an Aurelia app we are building.

It has appeared after upgrade from TS 3.1.x (now on 3.4.5).

For us the problem is exposed with declaration:true when we yarn link different packages together for dev.

I've been trying to put together a repro for you and have got something although it's not perfect (problem is only visible via VS Code and I havent been able to determine the difference in the CLI build).

If you clone https://github.com/simonfox/repro-plugin-one and https://github.com/simonfox/repro-plugin-two and run yarn for both. And then in plugin-one run yarn link plugin-two. Then you will see the issue in src/features/feature-one/actions.ts (you may need to reload the VS Code window after linking).

[simonfox]

Oh and probably importantly considering this seems to be exposed via symlinks, I am on Windows 10

[igorpupkinable]

Same here on Windows 10 x64 Pro.
I have created directory junction with D:\>mklink /j p D:\projects.
It works in D:\projects, but does fail in D:\p.

[antl3x]

@simonfox you found any workaround?

[simonfox]

@nthypes no sorry

[whimzyLive]

Getting same error here 😩 after upgrading to 3.6.3 from 2.9.1

[AnyhowStep]

Sorry, guys, I never did create a minimal repro for this.

But if you are getting assignability errors, it may have to do with classes with private properties, or unique symbols, which are nominally typed, and may not be assignable across different package versions.

Even if they're structurally typed, if the interface or type alias is different between the two versions, they won't be assignable to each other (which makes sense, in this case)

I still need to go ahead and make a repro for the assignability thing but I'm on holiday at the moment =x

Not sure if I can repro the OOM anymore, though