Typescript: TypeError: Cannot read property 'id' of undefined

[itslenny]

TypeScript Version: 1.8.10

I've noticed when I include javascript files in the files array of tsconfig (with allowJS enabled) I sometimes get some unexpected compile errors.

I've found a consistent repro with pixi.js. If I include it I get the error: TypeError: Cannot read property 'id' of undefined at getNodeId

This error occurs with the latest version (4.0.0-rc2) which can be found here: https://github.com/pixijs/pixi.js/releases

Additionally, I tested this with various versions of the library and observed the following

• version > 3.0.7 - TypeError: Cannot read property 'id' of undefined at getNodeId
• version > 3.0.0 - Out of memory
• versions 2.x - compiles as expected

TypeError trace:

TypeError: Cannot read property 'id' of undefined at getNodeId node_modules\typescript\lib\tsc.js:11646:18)
    at getNodeLinks node_modules\typescript\lib\tsc.js:12007:26)
    at checkExpressionCached node_modules\typescript\lib\tsc.js:20308:25)
    at node_modules\typescript\lib\tsc.js:13842:107
    at Object.map node_modules\typescript\lib\tsc.js:163:29)
    at getTypeOfVariableOrParameterOrProperty node_modules\typescript\lib\tsc.js:13842:57)
    at getTypeOfSymbol node_modules\typescript\lib\tsc.js:13958:24)
    at checkPropertyAccessExpressionOrQualifiedName node_modules\typescript\lib\tsc.js:18676:20)
    at checkPropertyAccessExpression node_modules\typescript\lib\tsc.js:18651:20)
    at checkExpressionWorker node_modules\typescript\lib\tsc.js:20394:28)

Out of memory output

<--- Last few GCs --->

13865 ms: Scavenge 1400.5 (1456.8) -> 1400.5 (1456.8) MB, 5.9 / 0 ms (+ 1.0 ms in 1 steps since last GC) [allocation failure] [incremental marking delaying mark-sweep].
14659 ms: Mark-sweep 1400.5 (1456.8) -> 1400.5 (1456.8) MB, 794.0 / 0 ms (+ 2.0 ms in 2 steps since start of marking, biggest step 1.0 ms) [last resort gc].
15458 ms: Mark-sweep 1400.5 (1456.8) -> 1399.0 (1456.8) MB, 799.4 / 0 ms [last resort gc].


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000027F7EA44A59 <JS Object>
    1: writeType(aka writeType) [node_modules\typescript\lib\tsc.js:13040] [pc=000001EB383DA8F4] (this=0000027F7EA04139 <undefined>,type=0000014D71F4DAB9 <a Type with map 000002E0B4251E69>,flags=8)
    2: buildTypeDisplay [node_modules\typescript\lib\tsc.js:~13035] [pc=000...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

[sandersn]

Here is a smaller repro:

function C()
{
    this.m = null;
}

C.prototype.m = function()
{
    this.nothing();
};

It doesn't run out of memory though; when you edit pixi.js to avoid the crash, the new version still runs out of memory.

[sandersn]

The root cause of the crash is that m has two declarations, but the code paths for this.m = null and C.prototype.m = ... are separate. The one handling this.m = null runs first, and it assumes that _all_ declarations are of the form this.m = .... This crashes when it hits the C.prototype.m = ... declaration.

[sandersn]

I have a fix up at #9574 for the crash. I am trying to compile pixi now and it hasn't run out of memory yet, but it also hasn't finished compiling after a couple of minutes...

[sandersn]

The out-of-memory error happens when a class has a property that's _not_ initialised in the constructor _and_ a method that returns this. Thanks to @vladima for debugging and finding the fix.

The property that's lazily initialised outside the constructor causes an error (that will ultimately be discarded instead of reported). In the course of constructing this error message, the compiler tries to stringify the ES3 'class'. Unfortunately, Salsa represents ES3 'classes' as anonymous types. The stringify code assumes that anonymous types aren't circular, but methods that return this actually cause a circularity.

The simplest fix is to change ES3 classes not to be anonymous types. However, we should consider not even producing checker errors in Salsa since they will be discarded, even though they may be quite expensive.

[sandersn]

Fix for the out-of-memory error is up at #9578. Thanks @vladima for the fix and debugging help.

[DanielRosenwasser]

@TheLarkInn and I tried running with --allowJs on the Webpack codebase and ran into both errors. It'd be good to see if this fixes things as well.

[sandersn]

how did you run it? I naively copied over the three files in node_modules/webpack/bin after installing webpack, then tried to compile with the tsconfig below. I didn't run into either error, so I suspect I'm not compiling enough of the code.

{
    "compilerOptions": {
        "allowJs": true,
        "out": "output.js"
    },
    "files": [
        "config-optimist.js",
        "convert-argv.js",
        "webpack.js"
        ]
}

[sandersn]

OK, I tried copying over everything inside node_modules/webpack and changing tsconfig.json to exclude node_modules instead of listing files explicitly. Now I get out-of-memory after trying to compile for several minutes.

If I apply just the out-of-memory fix, then I see the 'id' crash. Happily, the two fixes together allow TypeScript to compile webpack.

tl;dr: It works now.

[TheLarkInn]

Yay