[che-dev] Why do we need theia plugins?

[tmader@xxxxxxxxxx]

Hi folks,

Now that we have almost complete support for the VSCode languages API, the question arises why anyone would write plugins to the Theia API at all. In particular, we have planned work to port the Java and Typescript extensions to be based on the Theia plugin API. Folks from Typefox have raised that question whether it would not be better to simply run the VSCode (Java|Typescript) extensions. That would be desirable for us from a resources perspective: we could concentrate on one codebase and get more done.

This question is central to our plans for L-Train: we'll get started on plugin-fying java and typescript support around christmas latest, so (with me being on vacation next week and the Christmas shutdown), I would like to make a decision this week (at least on which way to start)

State of the plugin nation

First, here's how I understand what plugins have available in the environment where they run:

1. VSCode plugins

VSCode plugins get a partial implementation of the VSCode Extension API (https://code.visualstudio.com/docs/extensionAPI/vscode-api). It is referenced under the vscode namespace like:

vscode.workspace.createFileSystemWatcher(...)

I am aware that we soon will have a complete implementation of the languages and debug sub-namespaces, but I haven't found any documentation on the completeness (or intention to complete) for other namespaces (window, workspace, etc.)

2. Theia Plugins

Theia plugins get the same API as vscode plugins, but prefixed with 'theia'. So the above example would be 

theia.workspace.createFileSystemWatcher(...)

The theia namespace may contain API that is not documented in the vscode namespace: for example, theia offers a "call hierarchy" extension point that we intend to implement as a plugin API (https://github.com/theia-ide/theia/issues/3765). The typefox folk are pushing to get thei api included in vscode, but currently, the feature is Theia-only.

As I understand it, the theia API is exactly the same as the VSCode API where it occurs in both namespaces.

Obstacles to reusing VScode plugins

1. Theia-specific extensions

I'm pretty sure we DO want to be able to implement features that may not be in VSCode. That, howerver would require VSCode plugins and Theia plugins to cooperate on those features. If we want, for example to implement the call hierarchy API for Java, we would have to do two things: the first is to be able to invoke a custom command inside jdt.ls. For that we have to be able to contribute bundles to the jdt.ls process. In vscode-java, we have a mechanisme to contribute those bundles by mentioning them in the package.json. An analogous mechanism works for Theia plugins, but I am not sure it would work for a Theia plugin contributing to the jdt.ls running in VSCode-java.

Also, custom commands can be invoked in jdt.ls because jdt.ls exposes them through the commands API. But for some extensions (classpath), we would also need a way to react to custom notifications: My preferred way would be to expose custom notifications and commands as an API offered by the VSCode-Java extension. Calling the API from Theia-plugin to VSCode-Java should work.

2. Debuggers launch in wrong container

Looking through the existing PHP debugger VSCode extension, there is code that tries to run PHP as a child process of the debug adapter executable (https://github.com/felixfbecker/vscode-php-debug/blob/master/src/phpDebug.ts#L225). However, if we run this code in a Che plugin, the debug adapter would not run in the target container (the target container would not contain nodejs required to run the debug adatper). In consequence, the PHP process would be run in the PHP-tooling sidecar container. But that container may not even contain a PHP executable (since the tooling is written in typescript)

This means we cannot just blindly take over debug adapter VSCode-plugins. Some plugins will work correctly, but others may work fine in pure Theia, but not as a Che plugin.

Proposals

1. Reuse Java and Typescript VSCode plugins

2. Separate VSCode-compatible API from Theia-specific API

This would mean Theia plugins, as well would address API as vscode.workspace.crateFilesSystemWatcher(), but theia specific stuff theia.languages.registerCallHierarchyProvider(...) This would make it simpler to port existing plugins (like php debugger) to theia and to modify them for our needs.

3. Provide API in vscode-java (and typescript, etc.) to make sure we can write the extensions we need (classpath, etc.) as Theia (or vscode)-plugins

4. Verify we can do things like contribute bundles from theia plugins to vscode-java

I would be interested in getting feedback on my proposals: do you see technical obstacles that cannot be solved? How do you assess the risk this brings for our train goals? What did I miss?

/Thomas