TypeError: Cannot read property 'valueDeclaration' of undefined #34869
Comments
|
What's the content of |
RyanCavanaugh
added
the
Needs More Info
|
I was having this same issue with the new Typescript 3.7.2. The problem was the import below that's importing a Component.jsx /** @typedef {import('app/utils/validations').INVALID_FILE} INVALID_FILE */app/utils/validations.js export const INVALID_FILE = 'INVALID_FILE'; |
|
I've also seen this issue when upgrading to TypeScript 3.7.2 (3.6.4 works fine) I've narrowed it down so that I can only see the error ( /**
* @param {InstanceType<import('../../utils/templateUtils')['HasNoCostError']>} error
*/
constructor(error) {This is the syntax I currently use to annotate that a parameter is an instance of a class which is definied in a separate I've created a small gist which should reproduce the problem: https://gist.github.com/lukehesluke/8ef8e7061c6533e208e055aedb4e31b1 Keen to see how this develops and happy to help if that's useful |
|
I have the same issue. :( I have no ts files in my repository, and only a couple that use jsdocs to import jsdoc typedefs and none of them use imports like @lukehesluke Any advice for tracking down the offending file? |
|
I tried to get the declaration files for the openlayers project, but failed with error an error is thrown at code similar to #34926 (comment) |
|
Here's a sample code that'd reproduce this error: // test.ts
declare namespace ಠ_ಠ.clutz.jspb {
type AnyFieldType = boolean | number | string;
}
declare module 'goog:jspb.AnyFieldType' {
import AnyFieldType = ಠ_ಠ.clutz.jspb.AnyFieldType;
export default AnyFieldType;
}And here's the runtime behavior when type checking this code: // index.ts
import * as ts from 'typescript';
const program = ts.createProgram({
rootNames: process.argv.slice(2),
options: ts.getDefaultCompilerOptions(),
});
function visit(c: ts.Node): ts.ImportEqualsDeclaration|undefined {
if (ts.isImportEqualsDeclaration(c)) {
return c;
}
return c.forEachChild(visit);
}
let importEqDecl: ts.ImportEqualsDeclaration|undefined;
for (const root of program.getRootFileNames()) {
const sf = program.getSourceFile(root)!;
importEqDecl = visit(sf);
}
const tc = program.getTypeChecker();
const moduleRef = importEqDecl!.moduleReference;
const symbol = tc.getSymbolAtLocation(moduleRef)!;
console.error(ts.SymbolFlags[symbol.flags], symbol.name, symbol.valueDeclaration);
// Prints "TypeAlias AnyFieldType undefined"To execute, run Typescript version: 3.5.3 |
|
@RyanCavanaugh from what I can tell, the contents of |
|
To @lepsch's comment, I'll check and see if I am also importing a value instead of a |
|
Same is happening for us, the stacktrace only includes typescript files so i don't know what's causing it :( I tried on 3.8.0-dev.20191105 and it was still the same |
RyanCavanaugh
added
Bug
|
Same issue for me. |
|
I've created a branch in my project which illustrates the problem with After cloning this branch, run I know this is a far cry from a "minimal, reproducible example," but it's better than nothing. 😝 |
|
I just rolled back to the version 3.6.4: No errors with the same code. Hey @RyanCavanaugh, you have critical production bug here in your compiler! |
|
Is there a way to overcome this without downgrading to |
|
I have created a minimal example to reproduce the issue in OpenLayers. See https://gist.github.com/ahocevar/b3e58e7eac7750faa235ef66bdb559ab. The problem appears to be related to the |
When using `{import('./b').FOO}` which is defined as a string literal,
`valueType` doesn't have a `symbol`.
This was exposed in 8223c07.
Fixes microsoft#34869.
|
@ahocevar Thanks for that! -- I went through minimizing the "far cry" example above, which took almost the same time as getting through a far cry game, and got something manageable. The problem is when using an I checked that it's fixed now, but it'll still be interesting to look at since it's slightly different. |
|
Thanks for the fix @elibarzilay! |
When using `{import('./b').FOO}` which is defined as a string literal,
`valueType` doesn't have a `symbol`. Leave it for the fallback value
for now.
This was exposed in 8223c07.
Fixes microsoft#34869.
|
Has this been fixed? Here is my stack trace (the first one is react-styleguidist) |
|
Similar to what @jasonwilliams said, can someone please help me understand the state of this bug? Does that mean that this issue is fixed in |
|
@jasonwilliams, the stacktrace looks like it's in a different place, so probably a different bug... |
|
@elibarzilay the top of the first stack trace leads into the bottom of the second one. |
|
I'm seeing the same stacktrace as @jasonwilliams Version: typescript 3.8.0-dev.20191207 |
|
See above -- this issue was in the neighborhood of |
|
@elibarzilay right, so do you want me to make a new issue? |
|
@jasonwilliams, yeah, with its own repro (hopefully more minimized than the one for this...) |
|
Any update on this? I'm getting the error with the same stracktrace as @jasonwilliams, but unfortunately cannot narrow it down and make a repro as my project is pretty large and stack doesn't help at all. |
|
This has continued over at #35801 |
TypeScript Version: 3.8.0-dev.20191101
Running into this exception when trying to create declarations from
.jsfiles. Cannot use the Playground to illustrate this; it doesn't support.d.tsgenerationUsing
tsconfig.json:{ "compilerOptions": { "allowJs": true, "checkJs": true, "declaration": true, "emitDeclarationOnly": true }, "include": ["foo.js"] }Run
tsc, which should createfoo.d.ts. Run it again to get the error.Expected behavior:
a different error about refusing to overwrite
.d.tsfilesActual behavior:
This may or may not have anything to do with the fact I'm only generating declarations from
.jsfiles.The text was updated successfully, but these errors were encountered: