Auto-install VS Code extensions specified in `.vscode/extensions.json`

Is your enhancement related to a problem? Please describe

VS Code allows providing the extensions list (.vscode/extensions.json) that will be recommended for installation. The user needs to confirm that she really wants to install the recommended extensions set once VS Code starts (docs link).

While it looks great when running VS Code as a desktop application (Electron), it looks more like a redundant step when using VS Code in the cloud context.

Considering that one of the main goals of Che is to provide a fully ready environment for the developers, we can automate the step when the user needs to confirm what is already declared in the project’s config file. Not to bother the user by accepting pop-ups. Note, that in some cases there might be a few suggestions to install the extensions.

Everything described above might not be a big problem for the experienced VS Code user. But we see from the internal feedback that it is a problem for those who have no previous experience with VS Code. For people, it’s not obvious why the extensions declared in the .vscode/extensions.json config file are not actually installed in the running VS Code OOTB. Also, it turned out that for some users the relatively tiny notification in the window corner does not attract much attention:

Describe the solution you’d like

With the VS Code CLI, it’s possible to install the extensions set forcibly, without the user’s confirmation (docs link).

One of the options: the user can provide a dedicated attribute in the Devfile to tell VS Code that the recommended extensions, provided in the .vscode/extensions.json, are actually mandatory and must be installed without the user’s confirmation.

Release Notes Text

Recommended extensions in file .vscode/extensions.json are automatically installed by che-code at workspace startup. Before the developer get prompted to install them. This is the behavior we had in che-theia as well.

[azatsarynnyy]

okay, to sum up, what I’ve come to at this point. It’s mostly a note for myself, but probably might be useful for others as well.

While looking for a suitable solution for Che, I experimented with a few approaches. Probably, all my experiments deserve a blog post 🙂

• installing the extensions with the VS Code CLI switch --install-extension;
• calling the VS Code’s internal commands from a VS Code extension;
• adapting VS Code’s internal command or introducing a dedicated one that could be called from an extension and do all the required work;
• adapt the VS Code’s internal mechanism of detecting and installing the recommendations.

The 1st approach I tried was reading the extensions’ IDs from the .vscode/extensions.json file and installing all of them with the VS Code CLI switch --install-extension. While it seemed work well when testing it at the beginning, it turned out such approach might break the VS Code’s mechanism of the recommendations. At least, it will conflict with the VS Code OOTB experience. VS Code does much much more useful work related to the topic than just reading the content of the .vscode/extensions.json file and installing the extensions. Here are just some of the important aspects:

• VS Code workspace may be a single folder or multi-root. For multi-root, the extensions may be declared in the .code-workspace file. But may also be declared in individual folders as well;
• VS Code validates the extensions’ IDs and tries to resolve them on a marketplace;
• VS Code checks if some extensions were not added by the user to the unwanted list to ignore and do not recommend;
• etc.

The 2nd approach I’ve described in the comment above (https://github.com/eclipse/che/issues/21701#issuecomment-1310584719). The idea was to call a couple of VS Code’s internal commands from an extension to perform the same actions as the user if they agree to install the recommended extensions. The commands are:

• workbench.extensions.action.showRecommendedExtensions
• workbench.extensions.action.installWorkspaceRecommendedExtensions

The main command here is the second one. But it requires the Extensions view to be opened. So, we need the first one as well. The biggest challenge here is that there’s no way to be notified when the view is actually opened and if there are any recommendations present.

The 3rd idea was to introduce a new internal command that would do the required steps (similar to workbench.extensions.action.installWorkspaceRecommendedExtensions) but without the dependency to an opened Extensions view. When I started implementing it, I better investigated the VS Code internals and found an even simpler approach (⬇️).

The 4th one. I intercepted the VS Code’s default flow of suggesting the recommendations to install and called the installation of each verified recommendation in a way that all of them are installed just after the VS Code starts. The installation process goes silently, in the background, with no interaction with the user. After the installation is finished VS Code updates the workspace storage with the special value which means the user should not be asked for installing the recommendations on the next VS Code startup.

The main advantage of the last approach is that it preserves the VS Code’s default flow and eliminates any user interaction. This brings Che closer to an even more fully ready environment for the developers 🙂 This new behavior will be enabled default with the possibility to opt-out in the settings.

[l0rd]

Downstream issue link