Support VSCode API version 1.52

[voicis]

At the moment, it is not possible to use vscode-languageclient version 7.0.0 in Theia, because it requires VSCode API 1.52, but Theia only supports 1.50. In order for VSCode extensions that provide language features to work seamlessly in Theia, support for VSCode API version 1.52 should be added.

Feature Description:

This means VSCode extension that also want to be compatible with Theia, cant upgrade to vscode-languageclient version 7.0.0, because the extension will fail to start with the following error.

There are several features like semantic tokens, which are added with this vscode-languageclient version and are already supported by Theia, but it is not possible to use them right now.

To reproduce the issue you can use gitpod from this branch https://github.com/voicis/theia/tree/vscode-languageclient-7.0.0. It has a new plugin which is based no VSCode LSP sample extension from here https://github.com/voicis/vscode-extension-samples/tree/lsp-sample/lsp-sample.

[vince-fugnitto]

@voicis in your custom application you can always bump the version, or you can start your application with a higher version of the API. We should probably only bump the default version from the framework when we are satisfied that most of the APIs are supported:

theia/packages/plugin-ext-vscode/src/common/plugin-vscode-types.ts

Line 17 in 8d5e12a

export const VSCODE_DEFAULT_API_VERSION = '1.50.0';

$ cd examples/browser
$ yarn start --vscode-api-version=1.52.0

[voicis]

@vince-fugnitto wouldn't bumping the version when starting the application be dangerous? I assume VSCode extensions specify the required API version for a reason. If we just bump the version without having complete implementations then I expect that there will be problems when the extension will try to use API's that haven't been implemented yet. Please correct me if I'm wrong.

What I was looking for is some information about how many features are missing and when these missing features will be implemented, so the default API version can be safely increased.

Thanks!

[vince-fugnitto]

@vince-fugnitto wouldn't bumping the version when starting the application be dangerous? I assume VSCode extensions specify the required API version for a reason. If we just bump the version without having complete implementations then I expect that there will be problems when the extension will try to use API's that haven't been implemented yet. Please correct me if I'm wrong.

@voicis that would be an application's decisision, reading the issue it sounded like you wanted to bump the version to make use of the newer extensions which is why I suggested using the cli option. The framework should only be bumped when we are confident that most of the API is available for that version.

What I was looking for is some information about how many features are missing and when these missing features will be implemented, so the default API version can be safely increased.

I do not believe there is a timeline for when features will be added, but you can always look at the compatibility chart which is available from the website:

• https://che-incubator.github.io/vscode-theia-comparator/status.html

[voicis]

@vince-fugnitto I tried the workaround you suggested with the CLI option and it seems to be sufficient for our use case at the moment.

However, I suspect that other language extensions may start having the same issue as they upgrade vscode-langaugeclient version. This seems like a recurring problem with vscode-languageclient (#7243), whenever the required VSCode API version gets bumped there extensions using it can stop working on Theia, even though they are only using features that Theia supports and as extension maintainers, you are not generally in control of the Theia application, so this CLI option can't be used as a workaround.

[vince-fugnitto]

@voicis I'm not sure what the requirement is to simply bump our default API (% coverage of API support), but I did have some general idea of what might be necessary/recommended to update before we can bump. We would likely want to complete the following big items:

• Support for CustomExecution API (ongoing)
• Upgrade to the latest monaco (ongoing)
• Possibly upgrade electron (ongoing but perhaps not necessary)

This should however be a community decision, and perhaps it might be worthwhile for you to bring up to our next dev meeting.

[orboan]

Hello everyone,
when I use the latest Language Support for Java(TM) by Red Hat (0.79.2) in Theia, it requires 1.52 api vscode version, so I set --vscode-api-version=1.52.0, and as long as I tested it, it is working, but not all things and I know at some point it will fail, as I get these errors in console where I fired up theia:

root ERROR [hosted-plugin: 381] Response handler 'textDocument/foldingRange' failed with message: Cannot read property 'remove' of undefined

For example, automatically generating code for setters and getters does not work. The error in this case is:

root ERROR [hosted-plugin: 5087] Response handler 'workspace/executeCommand' failed with message: Cannot read property 'remove' of undefined

Can anyone tell me what how to find out what version of this plugin (Language Support for Java(TM) by Red Hat) is 100% compatible with 1.50?
Thank you

[tsmaeder]

As per @vince-fugnitto 's comment (#9193 (comment)), we now have custom executions and a new monaco version. Time to bump the number?

As for the future, it would be desirable to have some defined level of the vscode API that we support. If we choose not to implement something, we should have documentation on that. So the website would say something like

Theia support VS Code API x.xx.x>, with the following exception:

• The class vscode.xxx.foobar is not implemented
  ...

I think that would make it easier for adopters.

It would also be interesting to extract some data from OpenVSX to determine how many vscode extensions are on an older version in Theia because they request a later version of the VS Code API.

I would be interested to hear your thoughts about this.

[vince-fugnitto]

As per @vince-fugnitto 's comment (#9193 (comment)), we now have custom executions and a new monaco version. Time to bump the number?

I'm good to update the supported API version, and also include newer version of our builtins.
Please note that vscode-builtin-extension-packs are now supported at build time, meaning if we include 1.57.0 it will resolve to the latest API version if available. It also means one entry in the package.json is necessary now for all builtins.

As for the future, it would be desirable to have some defined level of the vscode API that we support. If we choose not to implement something, we should have documentation on that. So the website would say something like

For the most part I think we try to include everything, I don't think we choose not to support something?
It's more that support is not yet finalized for an API, so maybe we can make the api chart more visible by adding it directly to the readme, and possibly a wiki page?

It would also be interesting to extract some data from OpenVSX to determine how many vscode extensions are on an older version in Theia because they request a later version of the VS Code API.

There might be some queries we can do to open-vsx to gather this information, but I suspect a lot of newer versions of extensions are not being utilized due to their engines.vscode version.

[apupier]

Can anyone tell me what how to find out what version of this plugin (Language Support for Java(TM) by Red Hat) is 100% compatible with 1.50?

@orboan In theory, you should be able to look at the engines.vscode value:

https://github.com/redhat-developer/vscode-java/blob/453716f17244cdeb2aefb115c1aba3135737bfe6/package.json#L23

so for a 1.50.0 compatibility, it would mean 0.78.0

In practice, this is a pure declarative thing and maybe one of the real depeedencies have an higher requirements (and fo rthat you will need to check them and their transitive dependencies one by one) https://github.com/redhat-developer/vscode-java/blob/deef715ebaef57c548e6be22e0ef1820c36eb16d/package.json#L1084-L1092 But usually, the minimal requirement is coming from teh vscode-languageclient which is 6.0.0-next.8 and this one requires VS Code API 1.40.0 so good chance that 0.78.0 is the version that you are looking for.