Typescript: Cannot read property 'getEntryByPath' of undefined

[atrauzzi]

TypeScript Version: 2.9.2
Search Terms: _"Cannot read property 'getEntryByPath' of undefined"_
Code
I couldn't even begin to guess what code is causing this. It's obviously one of my dependencies, but which? Well -- I guess that's the problem with this error...
Expected behavior: Either my application to work, or for ts to give me better feedback.
Actual behavior: I get an error that doesn't help me identify where the issue is.

Happy to answer any specific questions beyond the basic template. It's a webpack 4 project.

[andy-ms]

Try shrinking the project size until you something that can be reproduced. Also, this error shouldn't show up in the command line compiler, so it must have something to do with a tool you're using to compile.

[atrauzzi]

I'm using webpack 4 with ts-loader.

I definitely can get it to compile by making a trival console.log module. But obviously there's a huge gulf between the modules my project uses and that.

Is there nothing I can do/use to get better insights?

[andy-ms]

I would recommend making a copy of your project, then deleting things until the error disappears. The error probably has to do with webpack's use of TypeScript services rather than the particular content of the code, but maybe the error only reproduces with some particular pattern of imports / file references.

(The error message is not too ambiguous, but that doesn't mean we know why it happened. There is indeed a line hostCache = undefined!; in the code that is fishy, but supposedly we had some reason why hostCache wouldn't be referenced after that.)

Also, try using typescript@next in case this has already been fixed.

[atrauzzi]

Tried @next before opening issue, didn't help.

So, I decided to go to that chunk of typescript.js and try to get some output:

            function fileExists(fileName) {
                var path = ts.toPath(fileName, currentDirectory, getCanonicalFileName);
                console.log(fileName, path);
                var entry = hostCache.getEntryByPath(path);
                return entry ?
                    !ts.isString(entry) :
                    (host.fileExists && host.fileExists(fileName));
            }

/Users/atrauzzi/Development/project/node_modules/@material-ui/core/package.json /users/atrauzzi/development/project/node_modules/@material-ui/core/package.json

So, it looks like it's failing when trying to access the package.json for material-ui? This happens several times in a row. Not sure what to make of it or how I could possibly identify who is responsible for causing the error...

• Is it typescript for...not sure...?
• Is it ts-loader because they misused typescript somehow?
• Is it material-ui because they are doing some kind of bad import?

I guess the issue here is that yes, we know there's an error, obviously. But the feedback doesn't narrow any of it down.

[andy-ms]

It would be better to just try getting a smaller repro -- right now there are just too many variables in play. For example, if you remove material-ui it might reproduce with some other package in your build.

[andy-ms]

If you're seeing compile errors instead of a crash, that probably means the thing you removed was relevant to the error.

[andy-ms]

This is a bug tracker -- you appear to have discovered a real bug, but to fix it we'll need a repro. My recommendation was to make a copy of your project and to simplify that so we have a way to reproduce the bug -- not to destroy your original project.

[atrauzzi]

Heads up, doing a lot of trial and error this evening and it seems to be narrowing down to any time I import WithStyles or withStyles from Material UI. Tomorrow morning I'll try to make a repro repo, but if I can't get it, I'll at the very least do screenshots. I can cause/prevent the error predictably now based on the one module.

[kasperisager]

I'm hitting this same issue when TypeScript tries to infer the type of a seemingly innocent constant that is assigned the result of a function invocation, with the function residing in a separate module. If I explicitly annotate the constant with a type, which also resides in a separate module, things work. I've however been unable to reproduce this in anything but my own code base, though it might provide others with a lead 😕

[jamalsoueidan]

It happens to my project too.

[atrauzzi]

Alright, managed to get a repro going based off of a slice of my project. All build configuration is included as well as the yarn-error.log generated, although that's probably not helpful.

---

Download repro archive.

To run:

yarn install
yarn hot

---

Here's the output I'm getting:

[michitaro]

I'm hitting the same issue too.
Here is my minimal reproducing repository.
https://github.com/michitaro/typescript-issue-25047
{"declaration": false} helps the situation.

This change solves the error in my case.
https://github.com/michitaro/typescript-issue-25047/commit/6f440e2128245e37a1de65b2a79d7399b9719461
VNode is a return type of the function.

[Qwerios]

I hit the same error and through trial and error managed to track it down to my import of redux-saga.

import { call, fork, ForkEffect, put, takeEvery } from 'redux-saga/effects';

ForkEffect was marked grey by VSCode because it wasn't referenced or used directly. It is used implicitly as a return type in the sagas.

Just sharing info to warn people that even if VSCode marks import as unused they might be needed for type completion or indeed compilation.

My project is based on https://github.com/alexjoverm/typescript-library-starter and https://github.com/ezolenko/rollup-plugin-typescript2 was giving me the error during build.

[atrauzzi]

Yeah, I definitely have had to start doing some arbitrary imports lately to get things compiling.

Setting your typescript version to ~2.8.0 will also dodge this issue, but obviously going down a version is no fun.

[TheSpyder]

I hit this and tracked it down to a file that, similar to the above examples, with TS2.8 fails to compile giving one of those Default export of the module has or is using private name errors. The type in question is coming from a library in node_modules.

TS2.9 doesn't throw an error compiling it, but the .d.ts file it produced includes types like this:

export declare const fn: (a: string) => import("../../../../../../../node_modules/mylibrary/Type").Type;

Which fails to parse in older tools.

As soon as I import the type, it changes to

import Type from 'mylibrary';
export declare const fn: (a: string) => Type;

which works.

[atrauzzi]

@TheSpyder - Are you sure it's 2.8.x where it's broken? I downgraded to 2.8.x and the problem went away. It's only on 2.9.x where I encounter this.

[TheSpyder]

In my case, 2.8 throws an error where 2.9 doesn't but it compiles weirdly :)

The 2.9 output is what's causing an error with rollup for me.

[andy-ms]

I've reproduced the bug without webpack:

node_modules/foo/index.d.ts

export function f(): I;
export interface I {
  x: number;
}

tsconfig.json

{
    "compilerOptions": {
        "declaration": true
   }
}

a.ts

import { f } from "foo";
export const x = f();

Just open a.ts in vscode and view the tsserver log.

    TypeError: Cannot read property 'getEntryByPath' of undefined
    at Object.fileExists (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:109416:39)
    at Object.fileExists (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82018:791)
    at getDirectoryOrExtensionlessFileName (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:84950:26)
    at tryGetModuleNameAsNodeModule (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:84939:35)
    at getGlobalModuleSpecifier (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:84742:20)
    at C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:84725:88
    at Object.mapDefined (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:541:30)
    at Object.getModuleSpecifiers (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:84725:29)
    at getNameOfSymbolAsWritten (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:32752:79)
    at symbolToTypeNode (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:32522:32)
    at typeToTypeNodeHelper (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:31971:27)
    at Object.typeToTypeNode (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:31804:41)
    at Object.createTypeOfDeclaration (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:53617:32)
    at ensureType (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:75521:41)
    at visitDeclarationSubtree (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:75820:88)
    at Object.visitNodes (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:59536:48)
    at transformVariableStatement (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:76090:28)
    at transformTopLevelDeclaration (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:76057:36)
    at visitDeclarationStatements (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:75915:26)
    at Object.visitNodes (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:59536:48)
    at transformRoot (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:75385:33)
    at C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:1349:42
    at transformRoot (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:76420:82)
    at Object.map (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:405:29)
    at Object.transformNodes (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:76407:30)
    at Object.getDeclarationDiagnostics (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:75214:25)
    at C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82436:27
    at runWithCancellationToken (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82172:24)
    at getDeclarationDiagnosticsForFileNoCache (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82433:20)
    at getAndCacheDiagnostics (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82446:26)
    at getDeclarationDiagnosticsWorker (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82430:20)
    at getDeclarationDiagnosticsForFile (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82459:56)
    at getDiagnosticsHelper (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82134:24)
    at Object.getDeclarationDiagnostics (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:82156:24)
    at Object.getSemanticDiagnostics (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:109519:50)
    at IOSession.Session.semanticCheck (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:116411:52)
    at C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:116450:31
    at MultistepOperation.executeAction (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:115923:25)
    at C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:115904:100
    at IOSession.Session.executeWithRequestId (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:117563:28)
    at Object.executeWithRequestId (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:116289:87)
    at Immediate.<anonymous> (C:\Users\anhans\AppData\Roaming\npm\node_modules\typescript\lib\tsserver.js:115904:41)
    at runCallback (timers.js:789:20)
    at tryOnImmediate (timers.js:751:5)
    at processImmediate [as _immediateCallback] (timers.js:722:5)

[andy-ms]

The problem is that getting imports uses moduleSpecifiers.ts as of #24610. That file uses host.fileExists in a few places. The implementation of that in synchronizeHostData calls hostCache.getEntryByPath, but hostCache was cleared earlier.

The line hostCache = undefined!; comes from #3331 -- there might be a performance penalty for removing that.

It looks like the use of hostCache in fileExists in services.ts is just an optimization, so we could fall back to always using host.fileExists if we've already deleted hostCache, but that could be slow.

Another fix would be to have the compiler keep a set of all the files it knows to exist from module resolution, so we don't have to ask a second time.

Opinions? @sheetalkamat @weswigham

[weswigham]

Graceful fallback to the fs feels like a given - since the hostCache is apparently undefined-able, it should be handled correctly when it is. A thin host cache that only holds resolution results but not contents might be a useful perf optimization, though; we'd have to test to find out.

[sheetalkamat]

The below change is must i think to fix this. HostCache is suppose to be valid only for duration of the program and thats what we shouldnt change

// services.ts
            function fileExists(fileName: string): boolean {
                const path = toPath(fileName, currentDirectory, getCanonicalFileName);
                const entry = hostCache && hostCache.getEntryByPath(path);
                return entry ?
                    !isString(entry) :
                    (!!host.fileExists && host.fileExists(fileName));
            }

But we could do better in getEmitHost in program by :

// program.ts
function getEmitHost(writeFileCallback?: WriteFileCallback): EmitHost {
            return {
                ... some stuff
                fileExists: f => {
                    const path = toPath(f);
                    if (getSourceFileByPath(path)) return true;
                    if (contains(missingFilePaths, path)) return false;
                    return host.fileExists(f);
                },
                ...(host.directoryExists ? { directoryExists: f => host.directoryExists!(f) } : {}),
            };

[thomasboyt]

Any chance that this feature could be backported to a 2.9.x release? Just lost two+ hours to this, and it's an absolutely brutal bug that I have to imagine has to be really common. As @andy-ms's tiny repro shows, anything that fails to import the return type of an implemented interface will just start erroring. In my case, I was seeing no errors in builds, but saw Intellisense in VSCode wasn't updating, and only by enabling TypeScript logging in VSCode did I find this exception and and issue! I wish I had earlier, as because I use a somewhat-complex monorepo setup that I've been changing a lot lately, I initially assumed I had messed something up in my tsconfigs, and I'm pretty shocked to learn it was actually a TypeScript bug this whole time.

I'll likely upgrade to 3.0.0 as soon as VSCode stable channel is updated so maybe this isn't too big of a deal, but I imagine other folks might be stuck on 2.9.x for various reasons.

[atrauzzi]

@thomasboyt - Any chance you can just jump to 3.x? I did and so far so good....

[trash-80]

Angular 6 is requires <2.10.0, so a backport would be nice.