Cannot read property 'getEntryByPath' of undefined #25047
Comments
|
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. |
|
I'm using webpack 4 with ts-loader. I definitely can get it to compile by making a trival Is there nothing I can do/use to get better insights? |
|
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 Also, try using |
|
Tried So, I decided to go to that chunk of So, it looks like it's failing when trying to access the
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. |
|
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 |
|
If you're seeing compile errors instead of a crash, that probably means the thing you removed was relevant to the error. |
|
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. |
|
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. |
|
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 😕 |
|
It happens to my project too. |
|
Alright, managed to get a repro going based off of a slice of my project. All build configuration is included as well as the To run: yarn install
yarn hotHere's the output I'm getting:
|
|
I'm hitting the same issue too. This change solves the error in my case. |
|
I hit the same error and through trial and error managed to track it down to my import of redux-saga. 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. |
|
Yeah, I definitely have had to start doing some arbitrary imports lately to get things compiling. Setting your typescript version to |
ghost
added
Bug
|
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 TS2.9 doesn't throw an error compiling it, but the Which fails to parse in older tools. As soon as I import the type, it changes to which works. |
|
@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. |
|
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. |
|
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 |
|
The problem is that getting imports uses The line It looks like the use of 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 |
|
Graceful fallback to the fs feels like a given - since the |
|
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 But we could do better in getEmitHost in program by : |
If we set declaration: true, then typescript (specifically rpt2, Rollup's TS plugin) fails with a cryptic path error. This is filed under microsoft/TypeScript#25047. Curiously, this does not happen on master, and I have vaguely traced it back to unionize and the fact that it does fancy type exports, which we partially re-export here. We would have to manually emit a declaration file, which is not hard tbh, but a bit annoying. Even funnier, webpack has no issue building in storybook, but that might be because it does not emit declarations anyway. Steps: - Get declaration file from master, add to repository, and copy to dist/ upon build; - See if massaging our exports fixes it; - Wait for TS :/
* Add utils and delayed loading test in stories * Intermediate solution Not sure where the reducer/update function is headed, but we'll find out, I suppose. * Finish refactoring * Make buffering work It works, but now the intersection logic is not the same. Scrolling until inView is true, and then up, triggers the promise cancelation. This is undesirable. We want the image to keep loading as long as it stays on the screen. Oddly, scrolling past the image, and it being in view, still lets it load without canceling (as intendeed). Another difference is that loading only commences once the image is fully in view, rather than on the margin. * Document things a bit better * There was no bug; the placeholder had a 0 height! * A few more docs * Name things, expose as props Added: - debugActions: logs actions in dev, warns and logs in prod - debounceDurationMs: whether, and how much to debounce loading, 0 by default, so no change to v1. Added codepath to make it so. - Provisional changes.md document with API compatibility - Various TODOs and cleanup tasks * Fix passing of debounceDurationMs to cb * Use debugActions in the story, destructure it Also add a note to hopefully remember to destructure next time :) * Pin microbundle and ts versions * Clean dir before build * TS BUG: need declaration: false to build correctly If we set declaration: true, then typescript (specifically rpt2, Rollup's TS plugin) fails with a cryptic path error. This is filed under microsoft/TypeScript#25047. Curiously, this does not happen on master, and I have vaguely traced it back to unionize and the fact that it does fancy type exports, which we partially re-export here. We would have to manually emit a declaration file, which is not hard tbh, but a bit annoying. Even funnier, webpack has no issue building in storybook, but that might be because it does not emit declarations anyway. Steps: - Get declaration file from master, add to repository, and copy to dist/ upon build; - See if massaging our exports fixes it; - Wait for TS :/ * 1.1.0-rc.1 * Version bump * Make update static, use Commands The Elm/JS/Redux/React-Component fusion is complete. The reducer is now a pure function, because it only describes side-effects, and does not execute them. The logic is really nice to read there. * Naming things * Version bump * Use TS3.0 * Copy definitions separately Because of the "path undefined" bug, we have to run `tsc` separately, to get the definitions and copy them over. * Do not expose Buffering as a separate state Expose it under 'Loading' for backwards compatibility * Improve debounceDurationMs docs * Add first point to README * Cancel Promises, clear cache on unmount * Add docs for debounceDurationMs
|
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. |
|
@thomasboyt - Any chance you can just jump to 3.x? I did and so far so good.... |
This is to get past an error when running the tests. Not sure if this version is too high for Angular, which is built at 9.2.9. But v9.2.9 throws ``` TypeError: Cannot read property 'getEntryByPath' of undefined ``` According to microsoft/TypeScript#25047 that version is the issue. It is fixed in v2.8 and v3. So we have to move or down.
This is to get past an error when running the tests. Not sure if this version is too high for Angular, which is built at 9.2.9. But v9.2.9 throws ``` TypeError: Cannot read property 'getEntryByPath' of undefined ``` According to microsoft/TypeScript#25047 that version is the issue. It is fixed in v2.8 and v3. So we have to move or down.
This is to get past an error when running the tests. Not sure if this version is too high for Angular, which is built at 9.2.9. But v9.2.9 throws ``` TypeError: Cannot read property 'getEntryByPath' of undefined ``` According to microsoft/TypeScript#25047 that version is the issue. It is fixed in v2.8 and v3. So we have to move or down.
|
Angular 6 is requires <2.10.0, so a backport would be nice. |
|
* Add utils and delayed loading test in stories * Intermediate solution Not sure where the reducer/update function is headed, but we'll find out, I suppose. * Finish refactoring * Make buffering work It works, but now the intersection logic is not the same. Scrolling until inView is true, and then up, triggers the promise cancelation. This is undesirable. We want the image to keep loading as long as it stays on the screen. Oddly, scrolling past the image, and it being in view, still lets it load without canceling (as intendeed). Another difference is that loading only commences once the image is fully in view, rather than on the margin. * Document things a bit better * There was no bug; the placeholder had a 0 height! * A few more docs * Name things, expose as props Added: - debugActions: logs actions in dev, warns and logs in prod - debounceDurationMs: whether, and how much to debounce loading, 0 by default, so no change to v1. Added codepath to make it so. - Provisional changes.md document with API compatibility - Various TODOs and cleanup tasks * Fix passing of debounceDurationMs to cb * Use debugActions in the story, destructure it Also add a note to hopefully remember to destructure next time :) * Pin microbundle and ts versions * Clean dir before build * TS BUG: need declaration: false to build correctly If we set declaration: true, then typescript (specifically rpt2, Rollup's TS plugin) fails with a cryptic path error. This is filed under microsoft/TypeScript#25047. Curiously, this does not happen on master, and I have vaguely traced it back to unionize and the fact that it does fancy type exports, which we partially re-export here. We would have to manually emit a declaration file, which is not hard tbh, but a bit annoying. Even funnier, webpack has no issue building in storybook, but that might be because it does not emit declarations anyway. Steps: - Get declaration file from master, add to repository, and copy to dist/ upon build; - See if massaging our exports fixes it; - Wait for TS :/ * 1.1.0-rc.1 * Version bump * Make update static, use Commands The Elm/JS/Redux/React-Component fusion is complete. The reducer is now a pure function, because it only describes side-effects, and does not execute them. The logic is really nice to read there. * Naming things * Version bump * Use TS3.0 * Copy definitions separately Because of the "path undefined" bug, we have to run `tsc` separately, to get the definitions and copy them over. * Do not expose Buffering as a separate state Expose it under 'Loading' for backwards compatibility * Improve debounceDurationMs docs * Add first point to README * Cancel Promises, clear cache on unmount * Add docs for debounceDurationMs
* Add utils and delayed loading test in stories * Intermediate solution Not sure where the reducer/update function is headed, but we'll find out, I suppose. * Finish refactoring * Make buffering work It works, but now the intersection logic is not the same. Scrolling until inView is true, and then up, triggers the promise cancelation. This is undesirable. We want the image to keep loading as long as it stays on the screen. Oddly, scrolling past the image, and it being in view, still lets it load without canceling (as intendeed). Another difference is that loading only commences once the image is fully in view, rather than on the margin. * Document things a bit better * There was no bug; the placeholder had a 0 height! * A few more docs * Name things, expose as props Added: - debugActions: logs actions in dev, warns and logs in prod - debounceDurationMs: whether, and how much to debounce loading, 0 by default, so no change to v1. Added codepath to make it so. - Provisional changes.md document with API compatibility - Various TODOs and cleanup tasks * Fix passing of debounceDurationMs to cb * Use debugActions in the story, destructure it Also add a note to hopefully remember to destructure next time :) * Pin microbundle and ts versions * Clean dir before build * TS BUG: need declaration: false to build correctly If we set declaration: true, then typescript (specifically rpt2, Rollup's TS plugin) fails with a cryptic path error. This is filed under microsoft/TypeScript#25047. Curiously, this does not happen on master, and I have vaguely traced it back to unionize and the fact that it does fancy type exports, which we partially re-export here. We would have to manually emit a declaration file, which is not hard tbh, but a bit annoying. Even funnier, webpack has no issue building in storybook, but that might be because it does not emit declarations anyway. Steps: - Get declaration file from master, add to repository, and copy to dist/ upon build; - See if massaging our exports fixes it; - Wait for TS :/ * 1.1.0-rc.1 * Version bump * Make update static, use Commands The Elm/JS/Redux/React-Component fusion is complete. The reducer is now a pure function, because it only describes side-effects, and does not execute them. The logic is really nice to read there. * Naming things * Version bump * Use TS3.0 * Copy definitions separately Because of the "path undefined" bug, we have to run `tsc` separately, to get the definitions and copy them over. * Do not expose Buffering as a separate state Expose it under 'Loading' for backwards compatibility * Improve debounceDurationMs docs * Add first point to README * Cancel Promises, clear cache on unmount * Add docs for debounceDurationMs
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.
The text was updated successfully, but these errors were encountered: