Support of unlisted extensions

[isidorn]

Creating his issue since we hear multiple requests for this, so we can keep all of them in one place.

We need to support "hidden" extensions in the marketplace. These extensions can not be searched for and users can not discover them. Assigning to you @prashantvc since I know you already worked on an initial document for this.

[ayim]

+1 from IntelliCode, this and the pre-release mechanism would help us deprecate some of the infra we maintain for our internal dogfooding extension :)

Our need for restricting access to the extension is for the extensive internal testing needed for our AI models/solutions. Some of them 'bake' for several months before we go to public preview.

[isidorn]

We are starting an investigation on unlisted extensions. Would the following behaviour be what you would expect? @ayim

There is a way to mark a version of an extension as unlisted in the publishing step (for example a vsce argument). If the latest version of the extension A is unlisted then:

• Extension A would not show up in search results, both on the Marketplace and in VS Code.
• Public publisher page of the author on the Marketplace will not show the extension.
• ~The webpage of the extension will not exist. For example https://marketplace.visualstudio.com/items?itemName= would be a 404~ edit: the extension page will not result in 404 @prashantvc
• VS Code will still be able to install the extension as part of an extension pack or an extension dependency.
• If extension A is installed, VS Code would still (auto) update it as if it were not unlisted.
• If extension A is installed, in the details page of extension A VS Code will render the unlisted badge.
• Users can continue to use the VS Code CLI to install an unlisted extension as they do today: $ code --install-extension <extension-id[@version]>
• Users can still download the unlisted extensions if they manually visit the url to the exact vsix location on the marketplace.
• [Optional] Marketplace manage UI displays if an extension is unlisted.

Open question: do we need to support extensions for which some versions are unlisted and some are listed. I think no. We should make our life easier and just respect the latest version.

Feedback is really appreciated, this is in a very early state. Thanks!

fyi @fiveisprime @sandy081 @chrisdias @anangaur does NuGet support a concept like this?

This is based on a paper written by @prashantvc

[tyaginidhi]

Looking at the proposed solution above, this is a useful solution for first time release of an extension as unlisted, and making it available to selected users for preview.

However, if we depend on just the latest version for making an extension invisible, all it is doing is stopping new users from discovering it. All the existing users still get the autoupdate to latest version. So, this cant really be used as a test mechanism for future extension releases, correct? What is the use case being targeted here?

Also, the proposed solution is quite similar to stable vs unstable version release of an extension. What's the key difference for existing users of an extension in this case?

[brettcannon]

I assume the extension will still be listed in VS Code's Extensions explorer once it's installed? One potential case I'm thinking about is we break out debugging support for the Python extension so it can be updated independently of the main extension. We would want to allow folks to pin the version of the debugging extension to support older versions of Python while letting the Python extension itself continue to update.

/cc @luabud

[isidorn]

So, this cant really be used as a test mechanism for future extension releases, correct?

Correct that is not the use case here. A test mechanism for future extension releases are pre-release extensions. Some use cases of unlisted extensions:

• Extension dependencies - when one of the dependencies does not really make sense to be installed independently. Brett's example from ☝️
• Some extensions that are built-in for vscode.dev routes and make no sense to live on their own in the Marketplace.
• Enterprise companies have extensions that only their employees use, and they would like them to live on the public marketplace but be hidden

@tyaginidhi Can you explain your needs a bit better? What is your team looking for exactly? Thanks!

@brettcannon yes, the extension will still be listed in VS Code's Extension view. Your use case sounds achievable with this proposal. Would there be a use case for Pylance as well?

[brettcannon]

Would there be a use case for Pylance as well?

That's more of a @luabud extension, but I think so since people will still be able to uninstall if necessary.

[alefragnani]

Hi @isidorn ,

Enterprise companies have extensions that only their employees use, and they would like them to live on the public marketplace but be hidden

Glad to hear you thought about this scenario. It’s a kind of private marketplace feature which has been requested for a while.

Open question: do we need to support extensions for which some versions are unlisted and some are listed. I think no. We should make our life easier and just respect the latest version.

I agree. The latest version should define its visibility

And I have a question:

• How about Extension Recommendation? I guess since unlisted extensions are installable via extension pack and extension dependency, it would also be installable/visible if recommended, right?

Thank you

[sandy081]

Another use case is to share libraries across extensions. For example, if there are multiple extensions depending on same library for eg .NET binaries then one can publish .NET binaries library extension (platform specific) and others can simple depend on this extension.

[prashantvc]

For example, if there are multiple extensions depending on same library for eg .NET binaries then one can publish .NET binaries library extension (platform specific) and others can simple depend on this extension.

This is how I imagined platform specific extensions to work in the beginning 😄

[bwateratmsft]

I had a slightly different idea; basically the extension would never show up in lists or search, but would show up if you accessed it directly by ID. So, not this:

The webpage of the extension will not exist. For example https://marketplace.visualstudio.com/items?itemName= would be a 404

It's not a huge difference but I can see there being useful scenarios based on that.

[joyceerhl]

The Remote Repositories extension could potentially benefit from being an unlisted extension. Remote Repositories is a library extension that both GitHub Repositories and Azure Repos extensions depend on. Remote Repositories should only ever be installed as a dependency of GitHub Repositories or Azure Repos, and shouldn't be directly discoverable by end users.

[prashantvc]

Small correction here:

The webpage of the extension will not exist. For example https://marketplace.visualstudio.com/items?itemName= would be a 404

This would not be a 404, but extension details page will be visible. Think this as Youtube's unlisted videos

[isidorn]

Two extensions that could profit from unlisted extension feature by @chuxel https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.vscode-dotnet-runtime https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.vscode-iot-device-cube

[isidorn]

I just had a great conversation with @xavierdecoster (NuGet) and here's some thoughts from that discussion:

• The unlisting (packages) feature on NuGet is mostly used by package authors as a way to "hide" specific versions of a package. And as a way to stop new users from getting that package, while old users of the package could still happily use it.
• VS Code actually does not have a use case for unlisted extensions. Difference is that in our ecosystem extensions is always on the latest version, and we already have support for extension deprecation as a "soft delete".
• Actual VS Code use cases are:
  1. Extension dependencies
  2. vscode.dev route extensions
  3. Enterprise extensions

Extension dependencies

@xavierdecoster and me agreed that the solution for (i) is to allow the extension to specify in their package.json that they are a "dependency" or that the extension should be "hidden". vsce would translate this from the package.json into the extension metadata. On the marketplace side we can support storing this metadata, since that part is already transitioned to PMP. Also the MP search service could respect this metadata, since the search is also transitioned to PMP and can access the corresponding db. So this could be achievable with the current Marketplace infrastructure.

The open question is how to name this package.json property. Should it be something like "dependency" : true or something more general like "hidden": true. If we go with the more general attribute then maybe this approach could be reused for other use cases.

vscode.dev route extensions

There are still some details missing from this use case that @bamurtaugh can help me with. Initial feeling from Xavier is that this could be solved on the vscode-unpkg layer.

Enterprise extensions

We need to understand how many enterprises actually want this, and if there is a need we could piggy back on the solution for Extension Dependenices case if we make the package.json property general enough.

Xavier and me plan to re-sync in September for the implementation details, in the meantime we should collect other potential use cases as well.

[luabud]

I agree Pylance would be a good use case here, and I quite like the dependency flag name/idea.

[prashantvc]

Extension dependencies

(i) is to allow the extension to specify in their package.json that they are a "dependency" or that the extension should be "hidden".

It means the author can control if an extension version is a dependency or hidden. IMO, this flag/property should be part of an extension, not a VSIX file/version of extension. If we maintain dependency property per version, it doesn't add any value

Enterprise extensions

Making a whole extension as dependency or hidden will help with enterprise use cases too

[xavierdecoster]

Extension dependencies

(i) is to allow the extension to specify in their package.json that they are a "dependency" or that the extension should be "hidden".

It means the author can control if an extension version is a dependency or hidden. IMO, this flag/property should be part of an extension, not a VSIX file/version of extension. If we maintain dependency property per version, it doesn't add any value

Some questions:

1. Is it fair to say that the latest version could define the flag for the whole extension?
2. Is it desirable for authors to define the flag as part of the extension manifest?
3. Is it desirable for extension owners to be able to toggle the flag after uploading to the registry?
4. Is it desirable for clients (e.g. VS Code IDE) to have the flag value available in the extension manifest (at consumption time)?

[isidorn]

@xavierdecoster thanks for thinking about this and for the great questions. Let me try to answer:

1. Yes. Just discussed this with @sandy081 and @prashantvc and we are in agreement
2. This is up for debate. We thought similar to the sponsor feature this is part of package.json, and then vsce transforms it to whatever is best for the MP
3. No, not needed. If they want to change, they should just upload a new version.
4. Not sure if we would need it that early. I think no, but @sandy081 would know best.

[reduckted]

I have a Visual Studio extension that I would like to deprecate (see #452). The behavior described in https://github.com/microsoft/vsmarketplace/issues/292#issuecomment-1206589931 sounds like it would suit my needs. A couple of questions though:

• All the behavior mentioned in this issue seems to refer to VS Code. Would Visual Studio extensions also be supported by this proposal?
• I'd really like to have a message on the extension page so that existing users of the extension can see why it has been deprecated. Would something like that be possible?

[prashantvc]

@reduckted Yes, VS IDE extensions will also benefit, however implementation can differ. We will have more details to share when we are ready :)

[prashantvc]

Some questions:

Is it fair to say that the latest version could define the flag for the whole extension? Is it desirable for authors to define the flag as part of the extension manifest? Is it desirable for extension owners to be able to toggle the flag after uploading to the registry? Is it desirable for clients (e.g. VS Code IDE) to have the flag value available in the extension manifest (at consumption time)?

1. Yes, we are in agreement. Latest version could define the flag for the whole extension. However, platform specific extensions can have multiple artifact files (VSIX file). I propose we read the hidden or dependency property from the latest version of the latest upload of an extension
2. This feature will be common for VS IDE and VS Code extensions; as VS extensions do not have a liberty to introduce a new property. I believe it's a good idea to have a flag in the UI/CLI in the marketplace
3. It is desirable, in a scenario where extension authors want to test an extension internally before making it public. We have seen this happen before with few of internal extensions.
4. This is up for discussion

[isidorn]

3. This might overcomplicate engineering work. Let's discuss once @xavierdecoster gets back from vacation. Anyways this is not a requirement for the VS Code team.

[rgrunber]

Another use case is to share libraries across extensions. For example, if there are multiple extensions depending on same library for eg .NET binaries then one can publish .NET binaries library extension (platform specific) and others can simple depend on this extension.

Just to add an example, https://github.com/microsoft/vscode/issues/124662 . The discussion proposed unlisted extensions because some users were upset to discover that one extension could install another (eg. that provides utilities) without explicit authorization. To achieve the same effect as hiding, the library was just made to an npm module with all dependent extensions contributing the exact same setting.

[ucheNkadiCode]

To add to this discussion, our team is looking to build an extensibility model for our container tools in which we would have common container library extension unifying multiple other extensions. However, in this case, the Common Container Library would be useless on its own and we wouldn't want users to download this extension thinking it has a use other than being a dependency.

Allowing this sort of extension to be unlisted with Microsoft approval would be great

[fbricon]

Another example of extension that should be unlisted: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-rsp-ui

cc @robstryker

[isidorn]

@fbricon can you provide more details how that extension is used? Does it fall under use case (i) from my comment above

[fbricon]

@isidorn indeed, it works as a dependency. Provides all the UI and API for managing application servers, but you need to install actual server providers, like redhat.vscode-server-connector or redhat.vscode-community-server-connector, in order to leverage it.

From the readme:

This extension on its own provides no support for any specific runtimes. If you install only this extension, the views and actions may appear not to function.

To be used properly, this extension requires other contributing extensions that provide implementations that start or stop specific RSP instances and are capable of managing specific server or runtime types.

[prashantvc]

We are seeing a pattern here, there are two requirements 1) library extensions 2) internal (unlisted) extensions that people want to share with limited set of people

1. Library extension cannot be installed explicitly, it is meant as dependency for other extensions (eg: Pylance or Remote Server Protocol UI). We want to allow extension authors to set flag in package.json that will prevent users from download/install these extensions independently. Something like allowExplicitInstall: false When allowExplicitInstall to false users can visit the extensions details page but Install and Download Extension buttons will be disabled

2. Internal (unlisted) extensions, we do not have solution for this yet, this is a requirement for both VS Code and VS IDE user we will have more details to share in coming weeks

[bwateratmsft]

For the scenarios of the Azure extensions, it's not that big of a deal if users install the "library" extension directly--functionality will be significantly limited--but I feel like blocking it outright is more than necessary. The primary thing we're interested in is suppressing it from search results on the marketplace, unless the exact ID of the extension is searched (i.e. the extension page still exists, and can be viewed normally, but just doesn't show up in search--much like unlisted YouTube videos).

[prashantvc]

@bwateratmsft Makes sense not to surface these extensions anywhere within the Marketplace website.

much like unlisted YouTube videos

We go back to square one with this :) This is something we will support eventually but with dependency we do not want them to be installed without the main extension

[bwateratmsft]

Right, I'm speaking specifically to the Azure extensions case, but that wouldn't necessarily apply broadly. Our extension model is designed such that the core "library" extension can be installed on its own (with limited but non-zero usefulness), and the depending extensions installed a la carte, but we expect the majority of users will install one of the depending extensions directly (thus getting the "library" extension due to extension dependencies).

If it means getting something "to market" (pun intended) sooner, I would rather have "unlisted" mean no more than "doesn't show up in search".

[prashantvc]

I wrote down a quick spec, please leave a comment or a question

Dependency extensions

Marketplace team will enable extension authors to publish dependency extensions. Dependency extensions are used as dependencies for a larger extension, they can be modular and may not provide any user interactions.

Now extension authors do not have an option to hide or restrict download of dependent extensions in the marketplace. For example, Pylance or Remote Server Protocol UI these extensions are not useful when installed without the main extensions.

Proposed solution

• We will allow extension authors to set a boolean attribute allowExplicitInstall in the extension's package.json file.
• The allowExplicitInstall will translate to AllowExplicitInstall in the VSIX manifest file on package. The default is always true if AllowExplicitInstall property doesn’t exists in the manifest file.
• When AllowExplicitInstall is set to false the extension details page will not show Install button and Trouble Installing link

• The manual download link will remain enabled to support offline installation scenarios.
• A dependency extension would not show up in search results, both on the Marketplace and in VS Code.
• Public publisher page of the author on the Marketplace will not show the extension.
• VS Code will still be able to install the extension as part of an extension dependency or an extension pack.
• VS Code would still (auto) update dependency extensions.
• Users can continue to use the VS Code CLI to install a dependency extension as they do today: $ code --install-extension <extension-id[@version]>
• Users can still download the dependency extensions if they manually visit the url to the exact vsix location on the marketplace.

Out of scope

• Support for VS IDE and AzDO extensions
• VS Code will not stop installing dependency extensions if it is installed manually.

[xavierdecoster]

Suggestion: can we reverse the naming and logic for the boolean? By default, booleans have a value of false.

Instead of allowExplicitInstall, I'd suggest disableExplicitInstall instead. Default value is false.

[prashantvc]

@xavierdecoster

Instead of allowExplicitInstall, I'd suggest disableExplicitInstall instead. Default value is false.

We didn't pick it because it's a double negative and bit confusing! @isidorn any thoughts?

[bwateratmsft]

I know the general guidance for Windows settings is "Allow" with a default true, instead of "Disallow" with default false. This isn't Windows of course, but IMO the guidance is still applicable.

[brettcannon]

• When AllowExplicitInstall is set to false the extension details page will not show Install button and Trouble Installing link

This may be a bit problematic for Pylance as that would mean if someone chose to uninstall Pylance they could not install it again w/o fully uninstalling the Python extension to trigger the re-install. Although I honestly doubt folks uninstall Pylance and then install it again later.

I assume uninstalling extensions would still be allowed?

/cc @luabud

[luabud]

Although I honestly doubt folks uninstall Pylance and then install it again later.

We actually do ask users to uninstall Pylance when the install seems to be corrupted for some reason, to then install it again. So that would be a problem indeed.

I also agree with @bwateratmsft -- if a user is looking for pylance explicitly (e.g. using its ID), I don't think it's a problem that they're able to install it directly. The key thing is that it doesn't make sense to show Pylance when e.g. looking for Python extensions in the marketplace. Forbidding explicit installs IMO doesn't help with the confusion problem we have about Pylance being an optional dependency. The ideal would have it not "show up in search" as Brandom brought up.

[isidorn]

@prashantvc thanks for driving this and for nicely summarising. I think this is a right direction and we are not too far off. Based on this great feedback from above ☝️ it seems like we need two independent package.json attributes:

"allowExplicitInstall": true (default) | false
"visibility": "public" (default) | "unlisted"

I believe with two attributes we will make it more explicit and clear to the extension authors. When visibility: unlisted the extension should also not show up in "Popular" or any other list on the MP. Alternative name "unlisted": true | false, but making it an open ended "visibility" would give us options to potentially extend it in the future.

I know this is not the same as NuGet unlisted, but I was swayed to use this wording because YouTube also uses it

fyi @sandy081 for thoughts

[prashantvc]

Updated specs based on the feedback

Dependency extensions

Marketplace team will enable extension authors to publish dependency extensions. Dependency extensions are used as dependencies for a larger extension, they can be modular and may not provide any user interactions.

Now extension authors do not have an option to hide or restrict download of dependent extensions in the marketplace. For example, Pylance or Remote Server Protocol UI these extensions are not useful when installed without the main extensions.

Proposed solution

Explicit install settings

"allowExplicitInstall": true (default) | false

• We will allow extension authors to set a boolean attribute allowExplicitInstall in the extension's package.json file.
• The allowExplicitInstall will translate to AllowExplicitInstall in the VSIX manifest file on package. The default is always true if AllowExplicitInstall property doesn’t exists in the manifest file.
• When AllowExplicitInstall is set to false the extension details page will not show Install button and Trouble Installing link

• The manual download link will remain enabled to support offline installation scenarios.
• VS Code would still (auto) update dependency extensions.
• Users can still download the dependency extensions if they manually visit the url to the exact vsix location on the marketplace.

Visibility settings

"visibility": "public" (default) | "unlisted"

When visibility is set to unlisted

• An extension will not show up in search results, both on the Marketplace and in VS Code.
• Public publisher page will not show the extension.
• The extension details page will show Unlisted badge when users visit the extension details page directly

• The visibility in the package.json can be accessed from Visibility tag in the manifest file when packaged

Regardless of above settings, users can continue to use the VS Code CLI to install a dependency extension as they do today: $ code --install-extension <extension-id[@version]>

Out of scope

• Support for VS IDE and AzDO extensions
• VS Code will not stop installing dependency extensions if it is installed manually.

[bwateratmsft]

Public publisher page will not show the extension.

@prashantvc just to clarify, that means the Publisher page, like this one for Microsoft: https://marketplace.visualstudio.com/publishers/Microsoft, and does not mean the individual extension pages would be hidden, like this: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azureresourcegroups, correct?

[isidorn]

@bwateratmsft correct.

[anangaur]

"visibility": "public" (default) | "unlisted"

IMO, visibility is a service side activity. It will be an anti-pattern if tomorrow a publisher wants to list (make visible) an extension that has visibility attribute set to unlisted. In addition, for a generic unlist feature, either the publisher or the service admins should be able to list/unlist any extension at will/requirements. Eg. for spam, critical bugs, vulnerabilities etc.

@prashantvc @xavierdecoster @isidorn

[bwateratmsft]

I don't think regularly changing back and forth between unlisted/public is the intended use case. For spam, GitHub has features already; for bugs and vulnerabilities, they should just be fixed--unlisting an extension will not help anyone with the extension already installed.

[isidorn]

Exactly what @bwateratmsft wrote ☝️
Unlisting here is unlike the nuget feature not something dynamic. It most likely holds true forever for an extension. Extensions changing the visibility is a corner case that should not happen.

[anangaur]

Sounds good. I would like us all to just flesh out any future scenarios that may require service side unlisting. If we need one, then it might be more prudent to do it one way than 2 different ways (i.e. adding service side visibility option in future after going with metadata route today).

Some questions with respect to extension dependencies:

1. How does uninstall happen with dependencies? Does vscode keep a reference count for dependent extensions?
2. Can there be standalone extension (that can be installed independently) that can become a dependency extension for other extensions, in future? What about vice-versa?

[isidorn]

Let me try to answer:

1. Users can go ahead and uninstall dependencies. This is not treated specially by VS Code. So if extension A depends on B. User can uninstall just B. If users uninstalls A that will also remove B.
2. Yes, this can happen. For example, any new extension introduced on the marketplace can depend on Python. And Python is an active extension that can be installed on its own.

[brettcannon]

For "allowExplicitInstall", will people be allowed to pin versions? The motivation for this question is we are planning to publish a debugpy extension (for debugging Python code). There's no reason to allow for (un)installing it separately, but since it would ship with Python code inside some users may want to pin to an older version (pinning to an older version is actually why we are going to ship a separate extension). This would also apply to us shipping the isort extension as a dependency of the Python extension.

[isidorn]

@brettcannon by "pin version" you mean the current feature in VS Code that user can choose the exact version? If yes that will be unchanged with this feature. If you mean a new feature that would control fixing versioning on the vs code side - then I would like to discuss this orthogonally to this discussion - and could you open a new feature request in the vscode repo for this? Thanks

[brettcannon]

by "pin version" you mean the current feature in VS Code that user can choose the exact version?

Yep!

If yes that will be unchanged with this feature.

🎉

[prashantvc]

Related issue #72