[vscode] add builtins to example applications

[vince-fugnitto]

What it does

The pull request updates both example applications (browser and electron) to use VS Code builtin extensions, and removes language specific extensions which will ultimately be deprecated.
The main idea is to easily develop and test against the builtin extensions and also quickly resolve compatibility issues with VS Code. Missing functionality should be replaced by appropriate and license certified external plugins.

The following builtins have not been added due to known issues/limitations:

Plugin	Reason
vscode-builtin-css-language-features	#6623
vscode-builtin-html-language-features	#6623
vscode-builtin-json-language-features	#6623, #6647
vscode-builtin-debug-server-ready	#6628
vscode-builtin-php	#6672
vscode-builtin-php-language-features	#6672
vscode-builtin-extension-editing	#6634, #3983
vscode-builtin-image-preview	#6636
vscode-builtin-git	-
vscode-builtin-git-ui	-

VS Code external extensions needed to support removed functionality:

• @theia/editorconfig > editorconfig - we will likely need to publish our own release
• @theia/tslint > tslint or even better eslint

Todo:

• refactor and generalize download-debug-adapters, and move it to @theia/cli
• find and add appropriate external VS Code extensions to compliment deprecated functionality
• update changelog
• add node and node2 extensions
  • package node ourselves since they do not have a .vsix release
  • package node2 ourselves since they do not have a .vsix release
• verify builtin licenses (create a script and verify through clearlydefined)
  • verified using the process defined in [licenses] productify license check for plugins (builtins + external extensions) #6926

How to test

Verify that CI successfully passes (examples should no longer pull removed extensions).

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

Signed-off-by: vince-fugnitto vincent.fugnitto@ericsson.com

[vince-fugnitto]

@akosyakov I'm not sure if for a first step we want to find external VS Code extensions (ex: editorconfig, tslint/eslint) and add them to the examples, or if it is in fact unnecessary.

[akosyakov]

I see that git, git-ui and merge-conflicts are skipped. For first 2 it is fine for first iteration, since many clients are prefer using Theia extensions instead, but merge-conflicts can be used instead of Theia extension. Did you skip something else? Could you list skipped in the description please?

[akosyakov]

I'm not sure if for a first step we want to find external VS Code extensions (ex: editorconfig, tslint/eslint) and add them to the examples, or if it is in fact unnecessary.

@vince-fugnitto If it does not harm dog fooding somehow (i.e. files get reformatted constantly without editorconfig, pushed code is bogus because linting errors are missing) then we call do it later, just file a follow-up issue. btw eslint extension can handle our tslint rules? if not then we should stick with tslint extension for now.

[akosyakov]

@vince-fugnitto please list what are reasons to exclude:

@theia/vscode-builtin-markdown-language-features
@theia/vscode-builtin-php-language-features
@theia/vscode-builtin-typescript-language-features
@theia/vscode-builtin-git
@theia/vscode-builtin-git-ui

We have to include @theia/vscode-builtin-typescript-language-features and it would be good to include @theia/vscode-builtin-php-language-features.

[akosyakov]

I think we also should add a record to CHANGELOG saying which extensions were deprecated and how to switch to built-in extensions.

[vince-fugnitto]

@vince-fugnitto please list what are reasons to exclude:

@theia/vscode-builtin-markdown-language-features
@theia/vscode-builtin-php-language-features
@theia/vscode-builtin-typescript-language-features
@theia/vscode-builtin-git
@theia/vscode-builtin-git-ui

We have to include @theia/vscode-builtin-typescript-language-features and it would be good to include @theia/vscode-builtin-php-language-features.

I will add `@theia/vscode-builtin-typescript-language-features 👍

I did not add @theia/vscode-builtin-php-language-features since the base @theia/vscode-builtin-php had issues. If you think they should be added I can do so.

As for git and git-ui, do you think it should be added now or at a later time?
I guess we need to see what to do with our git-history which ARM was keen on keeping.

[akosyakov]

I did not add @theia/vscode-builtin-php-language-features since the base @theia/vscode-builtin-php had issues. If you think they should be added I can do so.

ok, please update the PR description, it does not say reference any issue and seems to say that some extensions are excluded although they are included

As for git and git-ui, do you think it should be added now or at a later time?
I guess we need to see what to do with our git-history which ARM was keen on keeping.

yes, we have to figure out how we go with git, not everybody want to drop it yet

[akosyakov]

It looks good to me. @eclipse-theia/ecd-theia-committers Does anyone have objections?

• We will keep old extensions till theia-apps are migrated and then remove them.
• We may add java and python vscode extensions later if we will need them often.

@marcdumais-work Do we need any CQ process for vscode extensions? We don't distribute them, checking that they are under the compatible license by ourself should be alright, right?

[akosyakov]

I’ve tested new extensions, language coloring, typescript editing and node debugging work well.

[vince-fugnitto]

@marcdumais-work Do we need any CQ process for vscode extensions? We don't distribute them, checking that they are under the compatible license by ourself should be alright, right?

I verified the dependencies present in the builtin extensions from VS Code and everything looks fine 👍 I described the process in #6926 and plan to productify it in the future so we can re-use it if need be.

[marcdumais-work]

@marcdumais-work Do we need any CQ process for vscode extensions?
checking that they are under the compatible license by ourself should be alright, right?

Yes, like for npm dependencies, we need to do this recursively for all dependencies pulled by the built-ins as well.

I think we can do it ourselves, using a slightly adapted version of the self-check process we use for runtime npm dependencies. We just need to extract all the 1st level npm dependencies of the built-ins, and then we can follow the usual self-check process as documented in the wiki. This will need to be done each time we update the built-ins or other VS Code extensions we may have in the main repo.

We don't distribute them,

According to the Eclipse Foundation we do (once added in this PR), the same way we "distribute" runtime npm dependencies: by having Theia users pull them when e.g. they build this repo or build a Theia-based application.

[akosyakov]

Merging?

[vince-fugnitto]

Merging?

Merging! Thank you for your help @akosyakov @marcdumais-work 🍾

[tom-shan]

missing @types/tar ?

[vince-fugnitto]

Yes, that's correct. I added it as part of #6933 once I realized it was missing, but I will extract it to a different pull request:

• https://github.com/eclipse-theia/theia/pull/6933/files#diff-84c2900e9405f9a2214fe8a17c59b4d8R37