Make the Compiler and Language Service API Asynchronous

[DanielRosenwasser]

It makes very little sense that IO-bound operations (e.g. readFile, writeFile) are synchronous when we run on a platform whose touted strength is in writing IO-bound applications through asynchronous non-blocking APIs.

Compile times could probably be shaved down by a bit, especially for large projects with many files. Additionally, tooling experience should be as responsive as possible and avoid blocking in the event that IO takes place, enabling several optimizations to free memory on the managed side.

With #1664, this should be significantly easier.

This means that at the very least, the following would change to have asynchronous counterparts.

• createSourceFile (because of /// <reference ... /> comments)
• createProgram
• all of the language service API

[NoelAbrahams]

Compile times could probably be shaved down by a bit, especially for large projects with many files. Additionally, tooling experience should be as responsive as possible and avoid blocking in the event that IO takes place

👍

Does that mean you will ship and support a promise library?

[fdecampredon]

Honestly after the hell I have gone through to write brackets-typescript, and make languageService works in a webworker, I can only 👍 👍 👍 this one.

[DanielRosenwasser]

Does that mean you will ship and support a promise library?

I think it'd still be bring-your-own-promise; whatever we use would probably not be an official endorsement of what to use.

My own preference would be for us to use a polyfilled ES6 promise so that we can actually get a sense of how we support that scenario.

[basarat]

Just FYI : people will still need to run in a webworker (or separate node process). Making io async alone is not the performance bottleneck : TypeStrong/atom-typescript#36 (comment) Its just the sheer amount of computations that need to be performed.

[DanielRosenwasser]

Right - for an optimal experience, you really need to get some multithreading into the mix. In our case, we do some caching to avoid blocking IO operations, so this would help us in terms of reducing our memory footprint.

[vvakame]

👍

[basarat]

Definitely try https://atom.io/packages/atom-typescript again if you haven't before. Now I'm running a node (or atom on mac) instance just listening on stdin using this : https://github.com/TypeStrong/atom-typescript/blob/df110e7218815dc05be90102f46aad7bd2f04d29/lib/worker/messages.ts#L1-L50

With a parent : https://github.com/TypeStrong/atom-typescript/blob/df110e7218815dc05be90102f46aad7bd2f04d29/lib/worker/messages.ts#L1-L50

And a child: https://github.com/TypeStrong/atom-typescript/blob/df110e7218815dc05be90102f46aad7bd2f04d29/lib/worker/workerProcess.ts#L18-L36

There are still cleanups to do but the experience is awesome.

/cc (and thanks) @csnover

[basarat]

I've wrapped it up in an architecture that is extremely simple to understand / debug / extend. Also documented it (thanks to excellent support by @csnover) https://github.com/TypeStrong/atom-typescript/blob/master/CONTRIBUTING.md#architecture