Investigate improving the development support for TS server plugins

[mjbvz]

Investigate current TS server plugin development experience and understand how it can be improved

[kieferrm]

@egamma's development setup is described in https://github.com/angelozerr/tslint-language-service/blob/master/README.md.

[egamma]

@mattbierner I've reviewed the setup from the previous comment with @kieferrm. The setup has the issue that you need two different instances of VS Code and you debug in the instance where you do not expect it...

To support a better setup the Typescript extension should support an (internal) setting like typescript.debug.port that allows to define the debug port to be used by the TS server. With this setting the following setup would be possible.

• dev folder: the workspace that contains the plugin.
  • In this folder the user runs npm link to link the folder to the global npm registry.
  • there is launch.json to attach to the typescript server running the plugin (see below).
• test folder: the workspace with the manual test setup for the plugin.
  • This folder npm links the plugin from the dev folder into is local node_modules folder.
  • includes a .vscode/settings.json file that defines the typescript.debug.port setting used by the TS server.

With this setup the user opens a the dev folder in one window and the test folder in another one (similar to when developing an extension). To debug the plugin the user can run F5 from the development window to debug the typescript server running in the test folder.

settings.json in the test workspace:

"typscript.debug.port": 5860
...

launch.json in the development workspace:

    "configurations": [
        {
            "type": "node",
            "request": "attach",
            "name": "Attach",
            "port": 5860,
            "protocol": "legacy"
	    "sourceMaps": true,
	    "outFiles": ["${workspaceRoot}/out/src/*.js"]
        }
    ]

[mjbvz]

@egamma Would using the TSS_DEBUG environment variable work for this situation? Here's a launch config I prototyped for writing a vscode extension that loads a tsserver plugin:

{
    "version": "0.1.0",
    "configurations": [
        {
            "name": "Launch Extension",
            "type": "extensionHost",
            "request": "launch",
            "runtimeExecutable": "${execPath}",
            "args": ["--extensionDevelopmentPath=${workspaceRoot}" ],
            "env": {
                "TSS_DEBUG": "9000"
            },
            "stopOnEntry": false,
            "sourceMaps": true,
            "preLaunchTask": "npm"
        }, {
            "type": "node",
            "request": "attach",
            "name": "Attach to TSServer",
            "port": 9000
        }
    ],
    "compounds": [
        {
            "name": "Compound",
            "configurations": ["Launch Extension", "Attach to TSServer"]
        }
    ]
}

This compound debug config isn't perfect since the tsserver doesn't actually startup until the TS extension is activated, but it should give you a consistent port to targeted

[egamma]

@mjbvz this setup makes a lot of sense, when you develop the ts-plugin as a VSCode extension.

However, a ts-plugin is VS Code independent. It is just a node module that can be used by any editor/ide, it is not a VS Code extension. In fact the original developer of the tslint plugin node module is using Eclipse. The setup is that the tslint plugin is in a separate git repo. The node module is published to npm from this repo. The published node_module is then added as a dependency in the VS Code extension, pls see https://github.com/Microsoft/vscode-ts-tslint/blob/master/package.json#L43. In this way the node_module can also be consumed from eclipse, etc.

One idea would be to create a setup where the tslint plugin repo is used as submodule of the vscode repo, but I haven't looked into this one.

[mjbvz]

Ok. A different approach that @kieferrm and I discussed may more what you are after.

The goal with this approach was to allow testing a tsserver plugin using vscode, but without taking any actual decencies on vscode. To do this, we could create a vscode extension whose only purpose is to load a tsserver plugin that acts as a proxy for the actually plugin that you are working on at the root of your workspace.

Say you are working on the tslint-plugin, here's what your workspace may look like:

.vscode/
     launch.json
index.js
package.json
node_modules/
  vscode-tsserver-plugin-tester-extensions/
     package.json
     node_modules/
         tsserver-plugin-proxy/
             index.js
             package.json

• The root of the workspace contains the code for the tslint tsserver plugin itself. It has no dependencies on vscode (except for development)

• vscode-tsserver-plugin-tester-extensions is a vscode extension installed using npm. All it does is register a new tsserver plugin called tsserver-proxy-plugin with VS Code. The launch.json at the root of the workspace is configured to launch this extension. The process for attaching to the tsserver would be similar to what I described earlier

• tsserver-plugin-proxy is another tsserver plugin installed by vscode-tsserver-plugin-tester. All it does is forward calls to the plugin at the root of the workspace

The development experience would be similar to that of a VS Code extension. In this case, you still would be using VSCode for testing and development, but none of the code in your workspace would be VSCode specific

Would an approach like this help out at all?

[mjbvz]

@egamma Is there anything further we need to do for this issue?

[egamma]

@mjbvz there are several blocking issues to bring the ts-server based tslint support on par with the current vscode-tslint extension. I've therefore put this work on hold for now.

Since the angular-language-service plugin seems to make progress I suggest to hold back on additional work for now and close this issue or move it to the backlog.