upgrade to latest VS Code built-in extensions

[akosyakov]

Typescript now supports new syntax, like null coalescing and type imports. Extensions which we use cannot deal with it. I suggest we break it down to several steps:

• publish built-in extensions for April version of VS Code
• start using them in this repo
• some stuff won't work, collect issues
• fix issues

Maybe we should make it the standard practice after each VS Code release.

We could also start using them in theia-apps by introducing new insider tag, i.e.:

• latest means stable Theia and VS Code extensions
• next means unstable Theia but stable VS Code extensions
• insider means unstable Theia and VS Code extensions

@eclipse-theia/ecd-theia-committers WDYT?

[akosyakov]

We should also use latest stable tech supported by built-in extensions like #7693 to see these issues earlier in this repo.

[marcdumais-work]

Update: the first two items above are ready. The VS Code Builtin extensions v1.44.2 were published to open-vsx.org last week and the example app in this repo is now using them for the most part

• publish built-in extensions for April version of VS Code
• start using them in this repo

[akosyakov]

@marcdumais-work I wonder how we can routinise it?

[lmcbout]

Looking inside the package.json for the builtins, I see it requires node >12

• vscode-builtin-npm
  "@types/node": "^12.11.7"
• vscode-builtin-markdown-language-features
  "@types/node": "^12.11.7"

[akosyakov]

That seems to be only typings, does it break anything?

[lmcbout]

I was just mentioning that the 2 Builtins not working are both referencing this version of @type/node

[vince-fugnitto]

I was just mentioning that the 2 Builtins not working are both referencing this version of @type/node

@lmcbout I don't believe the node version for these extensions is the reason they are not working, you can see that there are missing APIs. Moreover, it looks like many of the extensions have this node @types version:

[marcdumais-work]

I wonder how we can routinise it?

Yes, we should be. Not much missing to automatically package and publish nightly - still working on it.

There's also an incoming enhancement in open vsx to add a stable URL for the most recent preview release in addition to the one for the stable version, of any given extension. So if we are willing to accept (occasional?) breakage here for the example app, we can eventually use the preview URL. Else we can at least use it for theia-appsfor insider images as per description above.

[akosyakov]

So if we are willing to accept (occasional?) breakage here for the example app, we can eventually use the preview URL.

I will prefer to know about breakage.

[marcdumais-work]

Update: we now have a GH workflow that publishes to https://open-vsx.org the solid revisions of the vscode builtins. Upon committing the PR, current latest, 1.45.1, was published. It will try again nightly, skipping already published extensions of that version, until a new vscode version is out.

[rgrunber]

We ran into an issue in vscode-xml that we traced back to updating from vscode-languageclient 7.0.0 to 8.0.1. Looks like vscode-languageclient started using more null-coalescing operators in the recent version and this prevents us from running. Is there any way around this ? Do we need to avoid using a library that uses null-coalescing if we want to run under Theia for now ?

[colin-grant-work]

@rgrunber, do you know what version of Node you're using? Nullish coalescence shouldn't be a problem for Theia, but it could be a problem for browsers or versions of Node that are too old for it. Theia is tested against Node versions 12, 14, and 16, and Node 16 (along with a new-enough browser) should be able to handle code that includes nullish coalesence (and optional chaining and other relatively new syntax).

See this discussion and this PR. The TypeScript plugin tested in #11083 included nullish coalescence, so it can't be used on Node 12, but Theia works fine with that plugin on newer Node.

[rgrunber]

@colin-grant-work , thanks. Yes I was using Node 12. Tried with Node 14 and the issue is gone now, though I seem to be getting TypeError: Class extends value undefined is not a constructor or null on class i extends r.TypeHierarchyItem, so I'll have to work through that.

[colin-grant-work]

TypeError: Class extends value undefined is not a constructor or null on class i extends r.TypeHierarchyItem, so I'll have to work through that.

Looking at our Plugin API, it doesn't appear that we support TypeHierarchyItem (yet) (as this confirms), so if the plugin attempts to access that class, it would still fail on activation (but this time, after parsing :-)).

[rgrunber]

Right. Thanks for explaining this. The issue is that vscode-xml make no use of the TypeHierarchyItem API. The stacktrace seems to imply as part of just initializing the language client, the TypeHierarchyItem is referenced so it's more than likely coming just from some initialization code. If that's the case, I don't see how we could update.

[JonasHelming]

@vince-fugnitto @marcdumais-work I believe we regularily do this now, hence we could close this issue, right?