TypeError: Cannot read property 'parent' of undefined

[ghost]

TypeScript Version: 2.0.3 / nightly (2.1.0-dev.201xxxxx) nightly (2.1.0-dev.20161018) Code ...

// A *self-contained* demonstration of the problem follows...
I just run tests written in TS with ts-node.

Expected behavior: It should work Actual behavior: Not sure what happened here. Was running tests with ts-node, and suddenly everything went very slow before I ran out of memory (I have 64 GB in this computer). A restart of the watch task resulted in this

typescript\lib\typescript.js:13542
                if (n.parent !== parent) {
                     ^
TypeError: Cannot read property 'parent' of undefined
    at visitNode (node_modules\typescript\lib\typescript.js:13542:22)
    at visitEachNode (node_modules\typescript\lib\typescript.js:12927:30)
    at forEachChild (node_modules\typescript\lib\typescript.js:13299:24)
    at visitNode (node_modules\typescript\lib\typescript.js:13546:21)
    at visitNode (node_modules\typescript\lib\typescript.js:12915:20)
    at forEachChild (node_modules\typescript\lib\typescript.js:13297:21)
    at visitNode (node_modules\typescript\lib\typescript.js:13546:21)
    at visitEachNode (node_modules\typescript\lib\typescript.js:12927:30)
    at forEachChild (node_modules\typescript\lib\typescript.js:13283:24)
    at visitNode (node_modules\typescript\lib\typescript.js:13552:29)
    at visitEachNode (node_modules\typescript\lib\typescript.js:12927:30)
    at forEachChild (node_modules\typescript\lib\typescript.js:13087:24)
    at fixupParentReferences node_modules\typescript\lib\typescript.js:13536:13)
    at parseSourceFileWorker node_modules\typescript\lib\typescript.js:13509:17)
    at Object.parseSourceFile node_modules\typescript\lib\typescript.js:13454:26)
    at Object.createSourceFile node_modules\typescript\lib\typescript.js:13313:29)node_modules\typescript\lib\typescript.js:13313:29)
....

[mhegazy]

We would appreciate a self-contained demonstration of the problem that we can use to debug the issue.

[ghost]

@mhegazy That's a very hard thing to do because I ran TS tests with ts-node. Then everything went slow and this message occured. I then installed TS 2.0.3 and everything works just fine. Later on I tested again with latest dev version, and same thing happened. However I suspect there is a 50% 50% fault here. That ts-node isn't updated to handle latest changes in TS dev version, and something wrong in the TS source code itself. For when I was looking at this, it seems to me that ts-node are doing some weird stuff.

At that time i was running a combo with Mocha + TS dev + ts-node. And I was using Mochas watch task. It was only when I used the watch task this happened. If I ran the tests normally it worked just fine. So maybe Mocha - my quessing - Mocha's require flag calling ts-node and ts-node calling TS dev code too many times ( because of the fact I ran out of memory) and then again ts-node isn't compatible with latest dev version, and I got the error shown above.

[mhegazy]

@zubuzon I am afraid i can not reproduce this with latest version of ts-node and typescript. without having a clear repro steps, or a sample input, this issue is not actionable.

[ghost]

@mhegazy It seems to have been fixed in latest dev version. I just ran the same tests again. So I'm closing this one.

[ghost]

@mhegazy I reopen this as I ran into it again. It seems to happen on different computers now with same setup.

"devDependencies": {
    "@types/chai": "^3.4.33",
    "@types/mocha": "^2.2.32",
    "@types/node": "^6.0.45",
    "mocha": "3.1.2",
    "chai": "3.5.0",
    "tslint": "next",
    "ts-node": "1.6.0",
    "typescript": "next"
  }

And in the tsconfig.js file

{
    "compilerOptions": {
        "allowJs": false,
        "allowUnreachableCode": false,
        "forceConsistentCasingInFileNames": true,
        "declaration": false,
        "experimentalDecorators": true,
        "moduleResolution": "node",
        "target": "es6",
        "lib": ["es7"],
        "noEmitHelpers": true,
        "newLine": "LF",
        "noImplicitAny": true,
        "project": "src",
        "noLib": false,
        "removeComments": false,
        "pretty": true,
        "strictNullChecks": true,
        "stripInternal": true,
        "sourceMap": false,
        "inlineSourceMap": false,
        "suppressImplicitAnyIndexErrors": false,
        "outDir": "lib/",
        "types": ["mocha", "chai", "node"]
}}

With this setup if you try to run Mocha watch task this happened.

 "scripts": {
    "build": "tsc -p src",
    "test": "mocha test/**/*.ts -R spec --bail",
    "watch:tests": "mocha test/**/*.ts -R spec --bail --watch"
  },

NodejS version I tried this one is 4 - latest (6.9.1).

Current TS version is latest nightly build.

Here are some ts/node stack traces;

 at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Module._compile (module.js:570:32)
    at Module.m._compile (node_modules\ts-node\src\index.ts:403:23)
    at Module._extensions..js (module.js:579:10)
    at Object.require.extensions.(anonymous function) [as .ts] (node_modules\ts-node\src\index.ts:406:12)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)

[mhegazy]

@blakeembrey does this sound familiar?

[blakeembrey]

Nope, never seen it. Trying to look through it, but without any way to reproduce I'm kind of stuck.

Edit: I'm ok moving the discussion to ts-node where I'm also responding now or keeping this open.

[ghost]

@mhegazy I know what's causing this, and it may be an surprise! Look at the latest post in this issue ticket: https://github.com/TypeStrong/ts-node/issues/224#issuecomment-255500697

It's the comment!

[mhegazy]

This looks like a TS bug then.

[ghost]

I don't know, but I also video recorded it. Should I send the video somewhere? It's clearly that's the comments fault.

[dead-claudia]

@mhegazy So you don't have to click each time, here's the two cases:

Failing:

/**
 * Define property
 *
 * @typedef {any} defineProperty
 * @property {[any]} [obj]
 * @property {[string]} [prop]
 * @property {[val]} [val]
 */
function defineProperty(obj: any, prop: string, val: any): any {

    return Object.defineProperty(obj, prop, {
        configurable: true,
        enumerable: false,
        writable: true,
        value: val
    });
}
export default defineProperty;

Passing:

/**
 * Define property
 */
function defineProperty(obj: any, prop: string, val: any): any {

    return Object.defineProperty(obj, prop, {
        configurable: true,
        enumerable: false,
        writable: true,
        value: val
    });
}
export default defineProperty;

I'm going to see if I can reduce this further on the playground.

Edit: it doesn't even repro. I'm going to try the nightly npm release.

[blakeembrey]

I created a repro from the ts-node issue. See https://github.com/blakeembrey/ts-and-ts-node-compile-bug-224, run npm install and npm test.

Edit: I can't reproduce without ts-node. I can repro without mocha using node -r ts-node/register test/index.ts.

[dead-claudia]

Here's a much smaller repro that fails 100% of the time for me. I can only get it reproducing with ts-node, not the CLI, so I highly suspect it's an issue with the language service. It's running on the latest nightly.

To test the repro, run npm install-test or ./node_modules/.bin/ts-node --no-cache index.ts.

[dead-claudia]

Things I noticed:

1. Both JSDoc properties don't match the body, and the second is technically invalid. If either of these properties are fixed, it immediately fails to reproduce.
2. All it takes is a reference to the exported variable for it to trigger, but import "./foo" does not trigger the bug.
3. It seems that the parser is being put in an invalid initial state by the language service in this case, so it can't correctly account for the invalid JSDoc comments.

[dead-claudia]

@mhegazy @blakeembrey Oh, and this doesn't reproduce in 2.0.3. It repros in 2.1.0-dev.20161022, though. That should help you all bisect it.