Reuse VS Code's extension host

[svenefftinge]

We should and could reuse the entire code that runs the extension host process.

I'm talking about everything in this folder: https://github.com/microsoft/vscode/tree/master/src/vs/workbench/api

Atm we are reimplementing the whole thing but I don't really understand why. Instead we should only implement the IPC protocol and run the extension host as is.

Doing this would

• reduce our code base by approx 30k lines of code
• will also fix many, many bugs and shortcomings
• will make it much easier to stay updated with vs code

The only downside I see is that we are no longer able to extend the API, which I'd personally be happy to trade for those benefits.

[svenefftinge]

So the 30k lines is what is in the respect VS Code folder. In Theia we currently have 14k LOC.
Might be that our programming is a bit leaner here and there, but it is more likely that we are just missing a lot of stuff.

[svenefftinge]

Another reason to go down this path, is that VS Code extension might 'hack' their way into non API things. E.g. gitlens does this:

https://github.com/eamodio/vscode-gitlens/blob/f22a9cd4199ac498c217643282a6a412e1fc01ae/src/commands/gitCommands.ts#L501-L502

[tsmaeder]

Not a fan, for various reasons:

1. We use the API namespace extensions in Che
2. We would still have to be able to override the way we run plugins: it's the basis of how we run remote plugins in Che.
3. It's hard enough to track a documented, versioned API. Relying on an internal API makes this even harder

CC @eclipse-theia/plugin-system because this needs discussion.

[benoitf]

let say you could reduce even more Theia's code if you grab https://github.com/cdr/code-server directly

more seriously:

The only downside I see is that we are no longer able to extend the API, which I'd personally be happy to trade for those benefits.

well Eclipse Che needs to provide others API namespace for VS Code extensions. (it's ok to not touch 'vscode' namespace) and we support plug-ins on the frontend side as well.

[svenefftinge]

I totally understand that this proposal seem a bit scary. But as the positive effects look so compelling I think it is worth discussing a bit more.

1. We use the API namespace extensions in Che

Would it be possible to implement those plugins as Theia extensions instead or do users actively install and uninstall them at runtime?

2. We would still have to be able to override the way we run plugins: it's the basis of how we run remote plugins in Che.

Starting multiple such processes in different containers should still be possible, I think.

3. It's hard enough to track a documented, versioned API. Relying on an internal API makes this even harder

I understand this argument in theory, but looking at the past changes on the RPC protocol it doesn't seem to be much different or even a little easier. Mainly because we will not have to catch up with everything that runs within the host process.

The underlying point here is that in order to eventually run all vs code extensions there should be no differences in the runtime platform (the host process). Manually rewriting the exact same thing doesn't make much sense and will keep us busy and in distance from the goal to fully support them and staying up to date with changes. I understand the custom namespaces feature is the only 'difference' to the original host process. The price we pay for this rarely used feature is extremely high.

[akosyakov]

We should at least reuse https://github.com/microsoft/vscode/blob/2305f2187475d860f5f70c8d3bff548f6ce08929/src/vs/workbench/api/common/extHostTypes.ts#L334 and make sure that it is easy to catch up with them. Right now it is not possible to compare it with https://github.com/eclipse-theia/theia/blob/master/packages/plugin-ext/src/plugin/types-impl.ts.

I've just found another bug Range.toJSON is missing and webview rely on this: #6578 (comment). Implementation of VS Code types should be exactly the same.

Looking at how much APIs we already covered, maybe it is not bad idea to reverse dependencies between theia plugins and VS Code extensions, i.e.

• we consume the extension host process as is, so only focus on main side, no more bugs in plugin host process
• but change its bootstrapping that new namespaces can be injected
• it would allow to get rid of mismatches between theia.d.ts and vscode.d.ts
• theia.d.ts would have only new APIs not defined in vscode.d.ts
• we can also consume the extension host code as dependency, so no need to CQ it anymore
  • it can be rebuild nightly and tested with vscode-api-tests

It sounds like a big refactoring, but we possibly can get rid of many small bugs and focus on IDE part more.