Che: VS Code Extension API does not work across Extension Host Boundaries

[tsmaeder]

A VS Code extension can provide API to other extensions by returning an API object from their activate function (see https://code.visualstudio.com/api/references/vscode-api#extensions.getExtension). This works fine when the extensions run in the same process, but when the extensions run in their own sidecar, I think this will not work.
This is relevant to Che: some very basic extensions like yaml support (https://github.com/redhat-developer/vscode-yaml) use this facility to communicate with other extensions like tekton support.

[tsmaeder]

There are really two approaches to solving this problem in the general case:

1. Make the VS Code API available remotely in all plugins hosts
2. Make sure all plugins that need to talk to each other run in the same plugin host.

The second one is really a non-starter, since it does not work in a plugin ecosystem where we do not control all possible combinations of plugins.

[benoitf]

I don't know if it's possible to use proxy(remoting) there

[tsmaeder]

@benoitf let's not give up before we try ;-)

[ibuziuk]

@tsmaeder could you please assign the right labels for this issue? which team is expected to work on this issue?

[amisevsk]

Another consideration with plugins like vscode-yaml is that this issue can create incompatibilities between unrelated plugins, if e.g. kubernetes tooling and quarkus both want to depend on vscode-yaml. It seems (from my testing at least) that only one instance of vscode-yaml will succeed at activating.

[tsmaeder]

It seems (from my testing at least) that only one instance of vscode-yaml will succeed at activating.

And that is the correct behaviour. Duplicate instances of plugins are bad.

[ibuziuk]

@benoitf which team is expected to work on the issue?

[benoitf]

@ibuziuk I would say editor as it's related to che/theia ?

[benoitf]

@ibuziuk AFAIK no need to assign team anymore no ? area labels are matching teams

[ibuziuk]

@benoitf this is new for me. We still need to assign the teams

[tsmaeder]

Cursory search revealed this. Not sure what it's worth, but it deals with transparent remoting of Javascript objects.

[benoitf]

the main issue is that all getExtension() / exports stuff is using synchronous calls (There are no Thenable in the vscode.d.ts defintion for this API) while with RPC/proxys we'll end up with Promises.

[tsmaeder]

Well, we can return a wrapper of the API object synchronously, but if the extensions themselves expose synchronous functions, there is a problem.

[benoitf]

getExtension is synchronous on this object you've exports field and then you call exported functions (and it can be sync or async functions)

we can return many wrappers but there is no guarantee that functions are asynchronous at the end.

it's the result of the activate method.
example
https://github.com/redhat-developer/vscode-yaml/blob/master/src/extension.ts#L88
https://github.com/redhat-developer/vscode-yaml/blob/master/src/schema-extension-api.ts#L34-L35

for that case, for void method it could work but not for the boolean one

[tsmaeder]

There are methods to force the remote access to be sync, but I guess that would be a bad thing, probably. But still, plugin API is broken across process boundaries. Can you think of another workaround for this?

[benoitf]

I'm still exploring :-/

[tsmaeder]

There's always https://github.com/ForbesLindesay/sync-request