You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
the end of the deleted Range (inclusive). DeleteLen was not always
accurate because editors normalize \r\n to \n in some cases, affecting
the length of ranges. In Diagnostic response items, changed len field
to end to address the same range length issue. Flattened
MessageDiagnosticChains in diagnostic message text, since clients expect
string there. Renamed ts.server.protocol to simply protocol in
session.ts and client.ts since module name prefix is clear.
Based on protocol feedback: Changed LineCol to Location. Changed
CodeLocation interface name prefix to FileLocation. Changed DiagEvent
to DiagnosticEvent. Removed anonymous types.
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 ❤️
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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,:
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.