Skip to content

Overview

Jump to bottom
Zhengbo Li edited this page Apr 13, 2017 · 1 revision

The plugin fires up a node language server by calling python's subprocess.Popen, and talks to the server via the child process's stdin / stdout.

Files

  • tsserver/: contains the typescript language service / compiler bits. Should be the same content as the TypeScript npm package

  • typescript/: contains the main logic of the plugin

    • libs: the infrastructure layer of the plugin. It deals with starting up the server / worker process, communication with it, and helper functions that commonly used in other files.

      • node_client.py: in charge of starting node and talking with it
      • global_vars.py: place to set global states. For example, sublime versions / logging verbosity levels etc.
      • service_proxy.py: a wrapper of the language service, with methods corresponding to each command provided by the language service.
      • editor_client.py: represents the editor-level operations. There should only be one instance of the EditorClient class (called cli right now) created when loading the plugin, and interactives with the server should by done via the service property of the EditorClient instance.
      • work_scheduler.py: currently only used to display popups.

    • commands: each file in this folder corresponds to a language feature. The naming convention of the commands and the way sublime invokes them can be found at the community documentation.

    • listeners: sublime text has a string of events that plugins can subsribe to. Files in this folder provides callback functions to one or more event hooks to invoke commands. The listeners.py is a consolidated place where we do all the event subscriptions (we only register this one file as to sublime); we do this because sometimes we need to control the order of execution among callbacks to the same event.

  • main.py: the entry point of this plugin that sublime calls at startup.

  • *.tmlanguage: the grammar definition file for syntax highlighting

  • *.YAML-tmlanguage: the YAML files that are easier to read than raw tmlanguage files and can generate tmlanguage files. Though the ones in this repo are outdates, use the ones at https://github.com/Microsoft/TypeScript-TmLanguage instead.

  • *.sublime-keymap: defines the keyboard shortcuts for the plugin. For OS specific ones, put them in the OS specific sublime-keymap file.

  • Preferences.sublime-settings: defines the user settings and the default values.

Trouble Shooting

There are several places where error could happen:

  • The plugin client side (python): if errors happen here, the first step is to see are there error / exception messages printed to the sublime console (View -> Show Console). If the information is not informative enough, try to set the LOG_CONSOLE_LEVEL to logging.DEBUG in global_vars.py or simply add print statement in the python code where you suspect could be the cause.

  • The language service side (node / javascript); to enable server side logging, you need to set an environment variable TSS_LOG to -level verbose. Then after a session look into the plugin's tsserver folder, there should be newly generated log files with names like .logxxxxx(for server) or ti-xxxxx.log(for type acquisition thread).

For the server, alternatively we can attach a node debugger to directly debug it. To debug the server:

  • Make the server start in --inspect mode (for node version > 6.0) by changing [node_path, script_path] to [node_path, '--inspect', script_path] in this line for windows or this line for non-windows. If you can to put a break point right after the server starts, add another argument --debug-brk after --inspect;
  • Open sublime, and then attach a node debugger via either VSCode or Chrome. Though only VSCode currently supports source map. Therefore if you want to debug a customized tsserver instance with the TypeScript code directly, VSCode is a better choice.

Other notes

The error list feature is a special one because when the error list is activiated, it creates a new instance of tsserver dedicated to do the project level error checking; therefore you will see two instances of node server running. However once the error list panel is dismisses, the second tsserver instance will be shutdown as well.

References

Clone this wiki locally