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

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.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 7
  • Comments: 26 (8 by maintainers)

Most upvoted comments

I see this bug is not in the 2.4.2 milestone. I think it should be, because it hampers libraries becoming compatible to 2.4, since it makes it hard for them to understand what’s wrong with their type definitions. It seems like a pretty big regression.

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

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.

I can confirm that setting skipLibCheck to true works.

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?