TS Server

[mhegazy]

The basic LanguageService interface puts some requirements on the "host", such as an implementation of a ScriptSnapshot system to support incremental parsing, managing contexts, monitoring files on disk, scheduling diagnostic queries, maintaining line map for line/column for positions for files, etc.. Every editor plugin is required to implement the expected host functionality, possibly in different languages.

This change exposes a new interface to the Services layer (ts server), through a JSON-based communication protocol. Behind the protocol, the server supports all the common host functionality,:

• A ScriptSnapshot management system with support for diffing script snapshots to allow efficient incremental parsing. A client would send a stream of text changes, and the server will maintain an updated version of the text in memory that can then be used to drive LS requests.
• A Project management service that allows for figuring project structure a la VS Virtual Projects, allowing the client to ignore resolving references, and maintaining project structure. The project management service also should supports different modes e.g. lose files, ts config, /// references, and imports. The client just informs the server about open files, and the server takes the responsibility of figuring out what files are interesting to this context. the client then asks for operations like completions, quick info, etc.. directly on the file.
• Managing closed file state without requiring the client to monitor them. The server adds file watches to all files in a project, and triggers re computation for errors and updates context once a file has changed on disk.
• Diagnostics update scheduling, the client does not need to trigger diagnostics update requests; the server sends events with errors whenever this is needed.
• A line/column interface with no need to keep a line map for all files. the server does not request any positions in its calls.

The server is mainly available as an IO process that a client would create in a separate process and communicates with it over stdin/stdout.

The change also adds a JS client implementation as a reference implementation to a client, and also used for tests.

The protocol definitions are all in protocol.d.ts.

Note: Reviewing the final change is probably easier.

[DanielRosenwasser]

Get this onto the same line as the =

[DanielRosenwasser]

This is awkward and a probably somewhat unnecessary.

[basarat]

I reviewed the TSServer code today as it exists in https://github.com/Microsoft/TypeScript/tree/master/src/server

I think its really nicely done in that it takes the burden of watching files + efficient snapshoting off of editor package authors.

The limitations for us is that it does not (and cannot easily using stdout) expose getProgram. This means that for really advanced features we would either need to wait for them to become a part of languageService or reimplement the stuff from TSServer. Also I use a globbing that isn't there in TSServer.

I am okay with using TSServer as a reference implementation and copying all the good stuff over. But just wanted to leave this feedback about my reasons for doing so (and potentially other package authors might end up doing the same thing). Thanks again for the initiative ❤️

ref : Based on TypeStrong/atom-typescript#91 /cc @csnover