Man page - tsserver(1)

Packages contains this manual

Package: node-typescript
apt-get install node-typescript

Manuals in package:

Documentations in package:

node-typescript

Manual

TSSERVERTSSERVER

NAME
NAME
Definition
Message format
Commands
NAME
Sublime text plugin
Visual Studio Code
Tide
Neovim
NAME
Logging
Cancellation
Commandline options

NAME

tsserver - TypeScript standalone server

The TypeScript standalone server (aka tsserver ) is a node executable that encapsulates the TypeScript compiler and language services, and exposes them through a JSON protocol. tsserver is well suited for editors and IDE support.

NAME

Protocol

Definition

The server communication protocol is defined in the ts.server.protocol namespace, declared in ‘tsserverlibrary.d.ts‘ .

The executable can be found in lib folder under the typescript package.

npm install --save typescript
ls node_modules\typescript\lib\tsserver.js

Message format

tsserver listens on stdin and writes messages back to stdout .

Requests are JSON following the protocol definition. Here is an example request to open a file c:/DefinitelyTyped/gregorian-calendar/index.d.ts :

{"seq":1,"type":"request","command":"open","arguments":{"file":"c:/DefinitelyTyped/gregorian-calendar/index.d.ts"}}

Responses are augmented JSON format. The Message starts with a header with the content length followed by a line separator ( \r\n ) followed by the response body as a JSON string:

Here is an example of a response for a quickinfo command:

Content-Length: 116

{"seq":0,"type":"response","command":"quickinfo","request_seq":2,"success":false,"message":"No content available."}

Similarly events have the same format as a response.

Here is an example event for error message:

Content-Length: 261

{"seq":0,"type":"event","event":"semanticDiag","body":{"file":"c:/DefinitelyTyped/gregorian-calendar/index.d.ts","diagnostics":[{"start":{"line":264,"offset":44},"end":{"line":264,"offset":50},"text":"Binding element ’Object’
implicitly has an ’any’ type."}]}}

Commands

tsserver supports a set of commands. The full list of commands supported by the server can be found under ts.server.protocol.CommandTypes .

Each command is associated with a request and a response interface. For instance command "completions" corresponds to request interface CompletionsRequest , and response interface defined in CompletionsResponse .
TSSERVER

NAME

Sample implementations

Sublime text plugin

TypeScript-Sublime-Plugin is a Sublime text plugin written in Python that uses tsserver .

Visual Studio Code

VS Code ’ s TypeScript support is implemented in TypeScript using tsserver .

Tide

Tide is an elisp implementation for emacs plugin using tsserver

Neovim

nvim-typescript is a neovim plugin using tsserver
TSSERVER

NAME

Advanced topics

Logging

tsserver logging is configured through the TSS_LOG environment variable.

TSS_LOG can have the following format:

Note: file defaults to __dirname\.log<PID> if not specified

Example : set TSS_LOG=-level verbose -file c:\tmp\tsserver.log

Cancellation

tsserver on startup will try to load module ./cancellationToken from the containing directory. This module should export a factory function

that accepts a list of command line arguments and returns HostCancellationToken . tsserver will use this token to check if in-flight operation should be cancelled.

NOTE: This token will be used for all operations so if one operation is cancelled and cancellation was reported through the token then when another operation is started - token should be reset into the

non-cancelled

state.

Default implementation of the cancellation token uses the presence of named pipes as a way to signal cancellation.

•

Before spawning the server, the client generates a unique name. This name is passed to the server as a cancellationPipeName command line argument.

	•		If some operation on the client side should be cancelled - client opens a named pipe with a name generated on step 1. Nothing needs to be written in the pipe - default cancellation token will interpret the presence of named pipe as a cancellation request.
	•		After receiving acknowledgment from the server, the client closes the pipe so it can use the same pipe name for the next operation.

Server can split execution of some commands (like geterr ) in a few steps that will be executed with a delay. This allows it to react on user actions more promptly and not run heavy computations if their results will not be used. However, it introduces a tricky moment in support of cancellations. By allowing request to be suspended and resumed later we break the invariant that was the cornerstone for default implementation of cancellation. Namely now requests can overlap so one pipe name can no longer be used because client have no reason

what request is currently executing and will be cancelled. To deal with this issue tsserver allows pipe name to be computed dynamically based on current request id. To enable this the client need to provide a value that ends with * as the --cancellationPipeName argument. If provided cancellation pipe name ends with * then default implementation of cancellation token will build expected pipe name as <cancellationPipeName argument without *><currentRequestId> . This will allow client to signal any request it thinks is in flight by creating a named pipe with a proper name. Note that server will always send

requestCompleted message to denote that asynchronous request was completed (either by running to completion or via cancellation) so the client can close named pipe once this message is received.