[2.4.1] stricter generic checks causes out-of-memory crash

[emmanueltouzery]

TypeScript Version: 2.4.1
node version: v6.10.3, linux x86-64

Code
https://github.com/emmanueltouzery/ng-typeview

clone the project, run:

• npm install
• tsc

Expected behavior:
the project compiled just fine up to typescript 2.3.

Actual behavior:
with 2.4.1, I get an out of memory at every run:

<--- Last few GCs --->

   44131 ms: Mark-sweep 1338.5 (1416.3) -> 1334.0 (1420.3) MB, 2112.0 / 0.0 ms [allocation failure] [GC in old space requested].
   46537 ms: Mark-sweep 1334.0 (1420.3) -> 1334.0 (1384.3) MB, 2406.1 / 0.0 ms [last resort gc].
   48675 ms: Mark-sweep 1334.0 (1384.3) -> 1334.0 (1384.3) MB, 2137.8 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 0x38bd260cfb39 <JS Object>
    1: set [native collection.js:~252] [pc=0x1a7da7795be3] (this=0x237efe5f2b39 <a Map with map 0x16e45b60a191>,r=0x3ebe4546afa1 <String[15]: 1359681,1359683>,z=1)
    2: /* anonymous */ [/home/emmanuel/.npm-packages/lib/node_modules/typescript/lib/tsc.js:~977] [pc=0x1a7da7953990] (this=0x163899f5ce41 <JS Global Object>,value=1,key=0x3ebe4546afa1 <String[15]: 1359681,1359683>)
    3: arguments ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0xde09ee [node]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [node]
 6: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, v8::internal::JSMapIterator, 2>::Allocate(v8::internal::Isolate*, int, v8::internal::PretenureFlag) [node]
 7: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, v8::internal::JSMapIterator, 2>::Rehash(v8::internal::Handle<v8::internal::OrderedHashMap>, int) [node]
 8: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, v8::internal::JSMapIterator, 2>::EnsureGrowable(v8::internal::Handle<v8::internal::OrderedHashMap>) [node]
 9: v8::internal::Runtime_MapGrow(int, v8::internal::Object**, v8::internal::Isolate*) [node]
10: 0x1a7da6c092a7
tsc --version
[1]    5209 abort (core dumped)  tsc

I've seen similar bug reports but no obvious solution (a bug suggested to increase the typescript dependency version, tried to increase that to 2.4.1, didn't help, tried to remove the typedoc dependency which has a transitive dependency to typescript, that didn't help either), and in some of these bugs typescript maintainers ask for the source and reporters couldn't provide it: here I can.

[IrickNcqa]

Same problem - different project. I'm using the angular template from the "Microsoft ASP.NET Core JavaScript Services" @ https://github.com/aspnet/JavaScriptServices, and was getting the exact same error while using Webpack's HMR in Node.

In trying to reproduce the problem from a minimal startup, I may have solved the problem in my case.

It appears that the rxjs/Subject.d.ts file no longer has valid definitions with the improved generic typechecking in v2.4.1. When I try a stock template, I get the following error in the browser:

ERROR in [at-loader] ./node_modules/rxjs/Subject.d.ts:16:22 TS2415: Class 'Subject<T>' incorrectly extends base class 'Observable<T>'. Types of property 'lift' are incompatible. Type '<R>(operator: Operator<T, R>) => Observable<T>' is not assignable to type '<R>(operator: Operator<T, R>) => Observable<R>'. Type 'Observable<T>' is not assignable to type 'Observable<R>'. Type 'T' is not assignable to type 'R'.

Alright, so that leads me to the skipLibCheck flag in the tsconfig.json file. The template includes the skipDefaultLibCheck flag set to true, but doesn't include the skipLibCheck flag. Double checking the flags at https://www.typescriptlang.org/docs/handbook/compiler-options.html, skipDefaultLibCheck is now deprecated in favor of skipLibCheck.

So, I simply replaced skipDefaultLibCheck with skipLibCheck (still set as true). That fixed the browser error about the d.ts file, and it also fixed the heap out of memory error in node (I'm guessing Webpack was silently failing on build because the now invalid d.ts file was being included, which led to the memory issue in node).

I checked your tsconfig.json file, and you don't have the skipLibCheck flag set to true. Maybe give that a shot and see if it fixes your problem too?

[myknbani]

Affects me too when I bumped TS to 2.4.1. Works fine with 2.3.4

[emmanueltouzery]

@IrickNcqa you're correct! Setting up skipLibCheck in my tsconfig.json gives me now normal build errors, which I assume are correct and due to the increased strictness of TS2.4.
My dependencies are quite up to date though. But I guess I must live with the flag for some time if I want to use 2.4.

[myknbani]

I can confirm that setting skipLibCheck to true works.

[myknbani]

Nevertheless, shouldn't this be considered a regression, since we did not need the skipLibCheck option before 2.4.1?

[emmanueltouzery]

@myknbani regardless of anything, tsc should never crash like it does in this bug. at the very least, even if the type definitions are invalid, it should display a proper error message.

That said, from my understanding, skipLibCheck won't be needed anymore once the libraries are updated for typescript 2.4. I do wonder whether we have worst type-safety for the broken libraries compared to TS2.3.x in the meantime though?

[IrickNcqa]

I'd say it's to be expected that stricter type checking would result in some new errors in existing type definition files. Given the above, it's clear rxjs needs to update their d.ts file, and in another thread it looks like the Redux d.ts is going to need an update also. There will probably be a lot of others.

So this will probably boil down to filing issues with the third parties to update their definition files or fixing ourselves and submitting. The major packages will probably be updated fairly quickly. TS v2.4.1 only dropped 20 hours ago - so they definitely haven't had time yet.

A bad d.ts file leading to a out of memory error is bizarre. Agree that needs improvement.

[IrickNcqa]

Looks like the heap error has been around. I just saw it in the v2.4.2 milestone, but no discussion of the skipLibCheck there. https://github.com/Microsoft/TypeScript/issues/16234

[emmanueltouzery]

for my app i'm not even sure which dependencies cause the issue. I suspect maybe immutable but I reproduce also removing that dependency. So a good error message should tell us which dependency is to blame otherwise it's going to be complicated to fix.

what I'd really like to know as well is, what is the downside of skipLibCheck?

does that make the type-checking of the libraries "lazy" and... if you don't use the feature which is badly mapped in the type definition then you have no problem and no regression in type-safety from 2.3. If you do use the feature which is badly mapped, then you still get the crash..

OR does it disable some type-safety and you are worse off on 2.4 with that option compared to staying on 2.3?

but yeah whether it's #1 or #2 it's probably better not enabling the option and sticking to 2.3 until the type definitions are ported to 2.4...

[IrickNcqa]

This bug is percolating all over the place. Just for rxjs...
Rxjs - https://github.com/ReactiveX/rxjs/issues/2539
Thread above: https://github.com/Microsoft/TypeScript/issues/16234
Another thread: https://github.com/Microsoft/TypeScript/issues/16593
Another thread: https://github.com/angular/angular/issues/17800?_pjax=%23js-repo-pjax-container

[sandersn]

I did a git bisect and found that it is a bug in the stricter generic checks introduced after 2.4.0 (at commit 368e5af).

For me, --noStrictGenericChecks also circumvents the crash, without sacrificing any other kinds of type checking. That's the workaround I'd recommend until the bug is fixed.

[sandersn]

By the way @IrickNcqa, #16234 is almost certainly a different issues since it predates the stricter generic type checking. There are lots of ways the Typescript compiler can run out of memory!

[axefrog]

@sandersn Just upgraded from 2.3.x to 2.4.1 and started getting the same error. I can confirm that adding the noStrictGenericChecks flag to my tsconfig successfully circumvents the issue.