Slow performance due to certain tsconfig opts

[brunohcastro]

My project uses the awesome angularclass angular2 webpack starter for the front end.

I started noticing the pending requests stacking up. The autocomplete suggestion take too long to show. It annoyed me so much that I migrated to sublime text.

But I really like Atom interface and how easy it is to customize it (and the open source part too). So I decided to check why the performance was so poor. I know this is a great plugin and it didn't make any sense.

This is part of the actual tsconfig.json from AngularClass/angular2-webpack-starter

  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "sourceMap": true,
    "noEmitHelpers": true,
    "strictNullChecks": false,
    "baseUrl": "./src",
    "paths": [
    ],
    "lib": [
      "dom",
      "es6"
    ],
    "types": [
      "core-js",
      "hammerjs",
      "jasmine",
      "node",
      "protractor",
      "selenium-webdriver",
      "source-map",
      "uglify-js",
      "webpack"
    ]
  }

So here is what I found out:

1. The tsconfig from angularclass starter project uses typescript 2 and take advantage from the @types packages to get missing definitions. To reference this typings, they use the "types" opt inside "compilerOptions" key. Removing it GREATLY improved the performance.
2. The "lib" opt also seems to have some impact in the performance, specially if you include the "dom" lib.

To add the types right and still use the @types packages, I just added one more line to the filesGlob:

    "filesGlob": [
        "!node_modules",
        "node_modules/@types/**/*.d.ts",
        "src/**/*.d.ts",
        "src/**/*.ts"
    ]

It is even easier now to add new types. They are automatically detected now!

So, I just opened this issue to report my findings and to help anyone that is having the same issue.
I hope that this report helps to solve this performances problems.

[calbear47]

I am having serious performance issues as well. It's awful...and it's only getting worse as my project grows.

I am using Angular 2 CLI with webpack. I followed your advice, but Atom is still struggling to process all the requests...sometimes over 50 just waiting in the queue. The whole point of TypeScript is to get intelligence prior to runtime and hopefully write better code faster, but with this performance, it's honestly worse.

I have included my tsconfig file if anyone has some suggestions...I'm all ears!

{
  "compilerOptions": {
    "declaration": false,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "lib": ["es6"],
    "mapRoot": "./",
    "module": "es6",
    "moduleResolution": "node",
    "outDir": "../dist/out-tsc",
    "sourceMap": true,
    "target": "es5",
    "filesGlob": [
       "!../node_modules",
       "..node_modules/@types/**/*.d.ts",
       "../src/**/*.d.ts",
       "../src/**/*.ts"
   ]
  }
}

[PeterZainzinger]

I also had performance issues with Atom, with Webstorm it's just fine without any modifications. Not a fix, of course, but at least a way of making a useable again.

[calbear47]

@PeterZainzinger Thanks for your 2cents.....I might have to give Webstorm a go. My brain just associated Webstorm with a bigger, heavier IDE that wouldn't perform any better, but I don't have anything to lose at this point...it's that bad.

[jeffschwartz]

If anyone is interested, I'm now using Visual Studio Code for all my JavaScript/TypeScript/Web development and it works great. The only thing it lacks for me when compared to Atom is a robust Vim add on package as good as the one Atom has but there are a few in development so I'm hopeful that will eventually resolve itself. Though both editors use Electron under their hoods, VSC just seems to run much smoother.

[brunohcastro]

@calbear47 In my tsconfig the filesGlob opt goes outside the compilerOptions key:

    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "emitDecoratorMetadata": true,
        "allowSyntheticDefaultImports": true,
        "experimentalDecorators": true,
        "sourceMap": true,
        "noEmitHelpers": true,
        "strictNullChecks": false,
        "baseUrl": "./src",
        "lib": [
            "es6"
        ]
    },
    "compileOnSave": false,
    "buildOnSave": false,
    "atom": {
        "rewriteTsconfig": true
    },
    "filesGlob": [
        "!node_modules",
        "node_modules/@types/**/*.d.ts",
        "src/**/*.d.ts",
        "src/**/*.ts"
    ],

Give it a shot!

[misaunde]

+1 on this issue.

Like @brunohcastro said, the autocomplete suggestion takes way too long...

[rsandor]

Yeah this is very intense, check out my queue after about 4 hours of work this evening:

18k and growing 😦 . Not sure what is up with this, but here's my tsconfig.json:

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "sourceMap": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "removeComments": false,
    "noImplicitAny": false
  },
  "atom": {
    "rewriteTsconfig": true
  },
  "declaration": true
}

Atom: 1.10.2
atom-typescript: 10.1.6

[piotr277]

+1 on this issue.
What worked for me was adding:
"exclude": [ "node_modules", "platforms" ]
to my tsconfig.json. After that the performance is ok.
I've got inspired by @leocorder from this thread: #1056

[rsandor]

@piotr277 - Much thanks, that improved performance all right. I had no idea that the auto-complete even worked! Now it seems to be doing pretty well, but it is still on quite the delay.

[github-actions]

This issue has been marked as stale because it did not have any activity for the last 90 days or more. Remove the stale label or comment or this will be closed in 14 days