TSC crashes on <30 line project

[bcherny]

Repro case: https://github.com/bcherny/tsoption/blob/7ae2d5d/index.ts (tree)

Repro steps:

1. Git pull tsoption@7ae2d5d
2. Run npm install
3. Run ./node_modules/.bin/tsc

Node version: 6.9.5
TypeScript version: 2.4.1

Error output:

$ ./node_modules/.bin/tsc

<--- Last few GCs --->

   31467 ms: Mark-sweep 1339.6 (1437.6) -> 1339.6 (1437.6) MB, 1460.1 / 0.0 ms [allocation failure] [GC in old space requested].
   32931 ms: Mark-sweep 1339.6 (1437.6) -> 1339.6 (1437.6) MB, 1463.8 / 0.0 ms [allocation failure] [GC in old space requested].
   34405 ms: Mark-sweep 1339.6 (1437.6) -> 1340.7 (1421.6) MB, 1473.7 / 0.0 ms [last resort gc].
   35885 ms: Mark-sweep 1340.7 (1421.6) -> 1341.8 (1421.6) MB, 1480.1 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 0x11cf6b9cfb51 <JS Object>
    1: getReturnTypeOfSignature [/Users/bcherny/Sites/tsoption/node_modules/typescript/lib/tsc.js:~27029] [pc=0x11e2ac7e930b] (this=0x11cf6b9e6f19 <JS Global Object>,signature=0x35a7fc95c541 <a Signature with map 0x210c46c5c571>)
    2: getReturnTypeOfSignature [/Users/bcherny/Sites/tsoption/node_modules/typescript/lib/tsc.js:~27029] [pc=0x11e2ac7e84ad] (this=0x11cf6b9e6f19 <JS Global Object>,s...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/Users/bcherny/.nvm/versions/node/v6.9.5/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/Users/bcherny/.nvm/versions/node/v6.9.5/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/Users/bcherny/.nvm/versions/node/v6.9.5/bin/node]
 4: v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/bcherny/.nvm/versions/node/v6.9.5/bin/node]
 5: v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/bcherny/.nvm/versions/node/v6.9.5/bin/node]
 6: 0x11e2ac2079a7
Abort trap: 6

[HerringtonDarkholme]

Changing type declaration to interface can solve this.

interface MonadNone<T> {
  ap<U>(option: Some<(value: T) => U>): None<U>
  chain<U>(f: (value: T) => Some<U>): None<T>
  chain<U>(f: (value: T) => None<U>): None<T>
}

interface MonadSome<T> {
  ap<U>(option: Some<(value: T) => U>): Some<U>
  chain<U>(f: (value: T) => Some<U>): Some<U>
  chain<U>(f: (value: T) => None<U>): None<T>
}

interface None<T> extends MonadNone<T> {
  flatMap<U>(f: (value: T) => Some<U>): None<T>
  flatMap<U>(f: (value: T) => None<U>): None<T>
}

interface Some<T> extends MonadSome<T> {
  flatMap<U>(f: (value: T) => Some<U>): Some<U>
  flatMap<U>(f: (value: T) => None<U>): None<T>
}

export type Option<T> = Some<T> | None<T>

export function None<T>(): None<T> {}
export function Some<T>(value: T): Option<T> {}

export let Option = <T>(value: T | null) => {
  if (value == null) {
    return None<T>()
  }
  return Some(value)
}

This problem is probably caused by caching. Anonymous object type will not be cached, so some recursive signature like (f: (value: T) => Some<U>) will incur exponential anonymous type instantiation. Thus OOM crash.

[fruchtose]

This seems like a big problem. TypeScript either needs to enforce a preferred type declaration scheme or support all type declarations equally. It's not enough for the official response to be, "just use interfaces". That makes writing TypeScript a guessing game.

[RyanCavanaugh]

@fruchtose at the risk of being obvious, us crashing is not a way of us telling you not to write a particular piece of code 😉

[fruchtose]

@RyanCavanaugh, I apologize if my response comes across as harsh. It's an issue that's started to crop up lately in my TS work. While it it's frustrating to have an issue to point to, it's a bit of a relief as well to identify a possible root cause.

[giniedp]

My team is also facing the same issue. Devs are getting annoyed, since we can not run incremental builds for TDD any more. Unfortunately it is closed source. But here is what i can tell so far.

• The error is same as above FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
• Occurs with typescript 2.4.x and also 2.3.x
• We are using webpack
• checked this guide
  • allowJs is false already
  • noImplicitAny is false already
  • transpileOnly is false already

When i search the project for type declarations, i can find about 134 matches. According to the comments above, those types wont be cached and may lead to out of memory. I tried to declare those types differently.

Some simple types can not be rewritten. Those look like

export type BrandColorName =
  "" |
  "dark" |
  "primary" |
  "secondary" |
  "success" |
  "warning" |
  "danger" |
  "info"

Majority of our types have been changed from this

import { AbstractControl } from "@angular/forms"
export class MyModel {
  // ...
}
export type MyModelForm = { [K in keyof MyModel]: AbstractControl }

to this

import { AbstractControl } from "@angular/forms"
export class MyModel {
  // ...
}
// next line is changed
export interface MyModelForm = { [K: string]: AbstractControl }

unfortunately this did not help. I still can get into the out the of memory crash. I can not say if the changes helped at least a bit, since i have no idea how to measure the compilers workload. I would appreciate any guide or hint how i could do that.

Even if the changes would have helped, i'd still prefer the type declaration like it was before the change since it helps us in 3 ways

1. allows us very easily to follow a convention where several types must have the same keys
2. no need to declare same keys across several types, which makes 1 a no brainer
3. intellisense, which is now obviously missing on the changed types

[HerringtonDarkholme]

@giniedp Probably your problem is deeper than OP's problem. And changing type alias to interface does not work probably proves it.

It seems that you have a quite large project. My suggestion is:

1. split your project into smaller sub-project so that you can compile fewer files in one time
2. deleting your code until TS stops OOM, this might help you find the root cause of crashing
3. set node's --max_old_space_size. This is the last resort that you can permit node to consume more memory.

Hope this helps.

[bcherny]

@giniedp Also see #13538.

[bcherny]

@HerringtonDarkholme Confirming that changing every instance of type to interface fixes the issue. However, as that is a workaround, have you guys thought about what it would take to fix the underlying issue?

[giniedp]

just to let you know. If i separate the typescript compilation from webpack then the bare tsc compilation runs in 13 seconds and only reaches 500MB of memory usage. Incremental compilation is then about 9 seconds. So that part actually looks good. Webpack is the one who does the heavy lifting while bundling.