I've published a VSCode extension.
Some users requested that I lower the minimum required VSCode engine version so that they can install the extension. https://code.visualstudio.com/api/working-with-extensions/publishing-extension#visual-studio-code-compatibility
The extension is a VSCode Web extension (works on both local VSCode and vscode.dev).
It looks like the VSCode Web was officially released along with VSCode v1.62.0.
But that does not necessarily mean that my extension won't work in, say v1.53.0.
So, what is the minimum VSCode version that supports Web extensions?
Another reason I want to lower the version is that some of my users might be using Eclipse Theia (VSCode fork) which lags behind the VSCode versions.
Related
Is there a standard way to handle Visual Studio Code inside a company network, in which VS Code is not allowed to contact the Internet?
For e.g. Eclipse, we can host our own update sites for plugins and can package pre-configured versions of the IDE for the developers.
Is there something similar for VS Code?
There are two ways (I know of) how you can provide pre-configured VSCode-installations
A) VSCode inside a Docker container. You'll have a minimal standard installation of VSCode on your computer, all plugins and settings come with the Docker image that is loaded into your local VSCode installation. See docs here: https://code.visualstudio.com/docs/remote/containers
B) VSCode web. This is a zero-installation version of VSCode which is running in the web browser. See docs here: https://code.visualstudio.com/docs/editor/vscode-web You can try it on GitHub: open any repo and change .com in the domain to .dev
I tried to sync my visual studio code settings / extensions. Many sync steps I did manual.
I found then these both tools
https://code.visualstudio.com/docs/editor/settings-sync
https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync
The first is from Microsoft and integrated (out of the box) in VScode. The second one is a high rated extension.
When I want to start a sync where should I start? Is there a recommended way? I cannot see many differences for the both tools.
My environment Win 10 with VScode and additional two times WSL2 Alpine and Ubuntu each with vscode.
Summary: Use VS Code's built-in Setting Sync for most cases. Use Khan's Setting Sync extension if you require multiple profiles (ie multiple settings) or you are running open source version of VS Code (such as VSCodium).
Before the official VS Code's version was released, the most popular way to sync VS Code settings across computers (and across platforms like Windows, Mac and Linux) was possible with Shan Khan's Settings Sync - Visual Studio Marketplace. This extension works really well, but it requires the users to set up their Github as it saves the settings to their private Gist.
VS Code had recently released its own Settings Sync, which unfortunately uses the same name as the extension, causing some confusion amongst the users. The built-in sync requires account in MS or Github. According to the VS Code documentation, it is completely different from Khan's Settings Sync extension. Now that the VS Code has introduced the feature of syncing, the writing might be on the wall for the extension. However, the extension has other features that is not available in the VS Code, so I think it will continue to be used and updated.
Khan's Settings Sync extension might be preferrable over the VS Code's built-in sync for some cases. Khan's Setting Sync can have multiple profile. Also OSS version of VS Code such as VSCodium doesn't include this feature, so the extension might be the only way to have this feature. Also, it is sometimes useful to be able to see different versions of your settings in Github Gist, as it maintains versioning. Finally, Khan's Settings Sync is also available for Azure Data Studio, which is based on VSCode.
the newest vscode update has the additional settings in which you can turn on the settings sync. Just go to file -> preferences -> settings sync. I used to use the extensions for my settings sync but now i don't use it anymore
I am developing my VS Code extension. Old version is 1.0.0. I add a new feature which leverages VS Code's new feature Remote-development, which only available with VS Code engine version higher than 1.36.1. I added my extension new feature and upgraded my extension to 2.0.0.
I would like to restrict user's VS Code engine when installing my extension. If user would like to install my extension v2.0.0, he must have VS Code engine version higher than 1.36.1.
I set the minimum VS Code version restriction in extension's package.json file, engines fields, following VS Code Official Docs: Extension Manifest. But later I figured out that user with VS Code engine version lower then 1.36.1 still can search my 2.0.0 extension and install it. VS Code does not pop out any suggestion to inform user to upgrade their engine. And the extension can not work properly, of course.
// package.json
"engines": {
"vscode": "^1.36.1"
}
Did I miss something?
How can I restrict user with lower VS Code engine version either to upgrade their VS Code engine or install the old extension release?
Now user with lower VS Code engine version just install my new extension release and the extension can not work. Any help is appreciated!
I figured out the reason myself:
VS Code package.json's engines field does work. If user's engine lower than the required minimum engine version, VS Code will install lower version extension for user.
In my scenario, I have a dependency extension, whose engine requirement is not aligned with the main extension. This is the root cause of the main extension installation failure.
When user with lower version VS Code engine tries to install my extension, VS Code checks the dependency extension's engine requirement and fails to find a main extension release with proper dependency release. In this case, the installation of main extension fails.
Solution:
I have to find a way to remove my previous extension release from marketplace, whose engine requirement is not right.
My team is developing a Visual Studio Code extension, and we're considering to release some of our new features as preview/beta only shown to a limited number of users.
We can think of ways to do it manually, but were wondering if Visual Studio Code provides any "standard" way to release such preview features, in a similar way as what is done for Visual Studio Code Insiders.
Is there a standard way to release preview features in VS Code extensions?
In vscode 1.63 an enhanced ability to preview pre-release extensions has been added, see release notes: pre-release extensions.
As VS Code now allows extensions to offer pre-releases, you can opt-in
to install them and use the latest cutting edge features from
extensions. VS Code shows an additional Install Pre-Release Version
option in the extension Install drop-down menu for installing the
pre-release version of the extension.
Once installed, the following indicators make it clear if you are
using the pre-release version of an extension:
If there is a pre-release version of an extension that you have
already installed you can easily switch to it:
To publish a pre-release version, see release notes: publish pre-release extension versions.
Publishing Pre-Release Extensions
VS Code now supports extension authors to publish pre-releases for
their extensions through vsce by passing --pre-release flag. You can
now make your latest features available to users who chose to install
pre-releases and get early feedback before the official extension
release.
vsce publish --pre-release
VS Code Marketplace only support major.minor.patch for extension
versions and semver pre-release tags are not supported. Support for
this will arrive in the future. Because of this we recommend that
extensions use major.EVEN_NUMBER.patch for release versions and
major.ODD_NUMBER.patch for pre-release versions. For example:
0.2.* for release and 0.3.* for pre-release. VS Code will auto
update extensions to the highest version available, so even if a user
opted into a pre-release version and there is an extension release
with a higher version, that user will be updated to the released
version.
More information about pre-release extensions can be found in the Pre-Release Extensions topic.
No, I don't think there's a standard way of doing this, which leads to different extensions taking different approaches:
The C# extension requires you to uninstall the marketplace / release version. Then you need to manually download the .vsix file for the beta release from GitHub and install the extension from that. It looks like the Go extension is taking the same approach.
Other extensions have two different versions published in the marketplace, such as PowerShell and PowerShell Preview. The latter has a preview badge in the marketplace by specifying "preview": true in package.json:
This approach also requires manually uninstalling or disabling the original extension before you can use the preview version.
Finally, some extensions include experimental features in regular marketplace releases, but lock them behind a setting so users can opt-in. There's some risk of breaking non-experimental functionality this way if things aren't tested well.
There's also an open feature request with a pretty lengthy discussion on this topic, so there might be an official solution someday:
Allow extensions to publish beta releases and users to opt-in to them (#15756)
I noticed today that VSCode is recommending plugins to me based on what applications I have installed locally.
For instance, if I hover over the recommended Sublime Text Keymapper, it tells me it is recommending it because I have Sublime Text installed.
Does anyone know if the matching between my installed apps and available extensions is done locally, or if the list of known installed apps is sent to a server somewhere?
It's local. Here's the code for it: https://github.com/Microsoft/vscode/blob/2b251d6e5ebefc2acdc6e73aae92ac2339b4984b/src/vs/workbench/parts/extensions/electron-browser/extensionTipsService.ts#L734
The non oss build just ships with a static mapping of executables names to extensions