Feature Request: Support for private marketplace/gallery

[levonmamikonyan]

We have created several VSIX extension that have no use to anybody else except our company. We would like to host our own private extension gallery and have an ability to specify alternative extension gallery paths (like "Additional Extension Galleries" in Visual Studio 2015).

• VSCode Version: 1.10.1
• OS Version: Windows 10

[flaix]

I'm also looking for a solution for an air-gapped network. We have set up local mirrors of Eclipse P2 repositories and for IntelliJ IDEA plugins, so that these extensions can be provided and updated at a central place and developers can install them into the IDE via the normal mechanism and also get updates. We would need the same for VSCode, which has a high demand amongst developers. Even if it is just, like llgcode said, a local URL from that extensions can be installed.

[jamesharris-garmin]

It seems like the simplest solution would be to open source the API to the extensions library (publish official endpoint documentation) Then allow individuals to implement the API via tools like sonatype-nexus. This would allow us to configure and internally mirror/proxy extensions/publish extensions to an internal server.

[dmpe]

Exactly, simple plugin for sonatype nexus would be enough for us as well. This currently prohibits our company from rolling out VSCode "officially"

[yuxuan]

Base on this issue https://github.com/microsoft/vscode/issues/81173 answer, I'm not sure private marketplace would be allowed unless there is non-extensions from MS marketplace.

My question is if we host a private extension server to serve internal extensions, and proxy other extensions to the official marketplace, does that violate MS terms.

There may have same situations in this thread. So I post question here.

[rfresow]

We are air-gapped too and would like a solution whereby we can use Sonatype Nexus.

[cniweb]

@rfresow we too!

[vannaka]

A possible solution for yall. @rfresow, this extension manager does let you use Sonatype Nexus! https://github.com/joelspadin-garmin/vscode-private-extension-manager. I believe this extension will be in the official vscode marketplace soon.

[ttutko]

Also in an air-gapped situation and we have used https://github.com/LOLINTERNETZ/vscodeoffline.

So far it has worked well for us in a completely offline environment. The only gotcha that we have run into is that some extensions attempt to reach out and download additional things from github or elsewhere when first run which does not work if you are offline, obviously. For those cases (python plugin is an example) you have to have an online machine that generally matches the os/architecture of your air-gapped machines and trigger the download there then move the whole folder over from your extensions directory. In other cases such as the C++ extension, the developers detect the failed download and give you a message in the log output on how to download an offline package of all architectures. Would love to see more extension developers do something like that when their extension requires reaching out to download something.

[joelspadin-garmin]

The extension @vannaka linked above is now in the official marketplace at https://marketplace.visualstudio.com/items?itemName=garmin.private-extension-manager

[prashantvc]

Hey Everyone!

I am Prashant, PM on the VS Marketplace team. The team that serves extensions to VS Code, we are in the process of prioritising the VS Marketplace backlog, I would love to get fresh perspective on this issue (both enterprises and individual needs):

1. What is your workaround for the current Marketplace limitation?
2. How do you manage the extension updates?
3. Are you allowed to install extensions from the Marketplace in addition to the private ones?
4. What is your current end-to-end experience like publishing/distributing/installation/update of a private extension?

Please email me at prchol@microsoft.com, we can set up a quick call

EDIT: You can pick the meeting time that works for you here: https://aka.ms/vsm-call

[RamyElkest]

@prashantvc any insight on the approach being taken.

[prashantvc]

@RamyElkest We are evaluating the multiple scenarios. We do not have anything to update at the moment.

[mdschweda]

What about the announcement of Theia? This seems like an opportune moment to prevent future segmentation.

[jan-dolejsi]

@prashantvc, my motivation was to ensure my users get the latest version consistently, without me having to beg them and push them. I did not need a marketplace gallery, where they would pick what they want. They will get pointed to the initial manual .vsix download (through various internal channels), but once they install it manually, they will be getting updates automatically.

I looked for something that I could do without deploying any other IT system, and ideally without having to deal with authentication myself. I was considering Azure Artifacts universal package (via the az CLI), Azure Artifacts NPM repository, O365 SharePoint, and Confluence Wiki. The last one is most accessible, because it happens to be installed inside the network, so for read/download no other authentication was necessary.

I wrapped it up in a small repo. And also separated an abstract base class, so others could implement adapters to other repository back-ends.

https://github.com/jan-dolejsi/vscode-extension-updater

[mdschweda]

https://github.com/eclipse/openvsx

[joelspadin-garmin]

@prashantvc I'm not sure if I have time for a call anytime soon, but to answer your questions:

1. I wrote an extension to manage other extensions from a private server.
2. The extensions are on a private NPM registry. We publish extensions as NPM packages to it.
3. Yes.
4. See answer 2 for publishing. For distributing, users either add the URL of the private server to a setting, or we add a file similar to extensions.json to our repos which has that URL and any recommended extensions. The Private Extension Manager lists the available extensions and handles installation and updates from there.

The goals of this solution are:

• Keep extensions which might contain proprietary info on a server we control.
• Make it easy to find and distribute extensions, especially extensions relevant to specific projects.
• Handle extension updates.
• Make it easy to find whatever does all of the above (hence making the extension manager open source, so we can recommend it in an extensions.json).

[jamesharris-garmin]

A further comment I would make regarding this: We tend to have a policy of wanting to do transparent mirroring proxies for mission critical resource, that way if something happens that takes down large sections of the internet we are insulated with our own mirrors. We achieve this using tools like Sonatype's Nexus or Jfrog's Artifactory so the ability to setup a similar capability would be useful to us.

[axi92]

We are using this https://github.com/joelspadin-garmin/vscode-private-extension-manager and a npm repo in nexus. Works very well!

[sr229]

Our friends from @eclipse Made OpenVSX. Give it a shot.

[Surendrajat]

Any updates on this one? I'm also looking for the same.

[ludakhris]

Any official updates?

[yuzhidi]

Our friends from @eclipse Made OpenVSX. Give it a shot.

Do your friends deployed OpenVSX locally?

[yuzhidi]

We are using this https://github.com/joelspadin-garmin/vscode-private-extension-manager and a npm repo in nexus. Works very well!

nexus should be paid?

[axi92]

We are using this https://github.com/joelspadin-garmin/vscode-private-extension-manager and a npm repo in nexus. Works very well!

nexus should be paid?

Nexus3 OSS is free to use =)

[svenefftinge]

Do your friends deployed OpenVSX locally?

You can deploy it locally, yes. https://github.com/eclipse/openvsx

[GitMensch]

You can deploy it locally, yes. https://github.com/eclipse/openvsx

... and then override marketplace in product.json for your users to point to your locally deployed OpenVSX installation. That way you check which extensions (and versions) you want to have, push those to your local open-vsx and let the users work with that.

For the initial user-setup I'd suggest to create an "empty" vscode project (or code-workspace) with extensions.recommendations setup to include all extensions the users should have (or create separate ones for the separate teams, for example one java/.vscode one python/.vscode and one common/.vscode; then depending on the team the users has to only open the correct workspace with the recommended extension setting, then clock on "yes install all recommended extensions" and is setup. When you later push new versions to open-vsx they will be automatically updated.

[carmenbreezy]

Any updates on this?

[GitMensch]

If there's interest I'd create a PR to override the marketplace endpoints with environment variables (if they aren't set the product.json wins, I guess this may be acceptable).

[feldoh]

@GitMensch that would be an excellent tradeoff

[YonathanB]

4 years and still waiting for that feature!!

[kjsingh]

I am the 770th customer waiting for this feature!

[GitMensch]

OK, we have a PR to fix this >4 years issue now, only needing someone to review and pull that. If given some hints about where to add this I'll create a follow-up PR to vscode-docs...

This would really help to use vscode in environments that are disconnected from the internet and/or not allowed to install any extension they like, which is both not uncommon in corporate environments.

[prashantvc]

OK, we have a PR to fix this >4 years issue now, only needing someone to review and pull that.

Adding Sandeep's comment for visibility https://github.com/microsoft/vscode/pull/129764#issuecomment-889155248

[isidorn]

Upstream issue https://github.com/microsoft/vsmarketplace/issues/167

[GitMensch]

@isidorn The upstream issue was closed one hour ago, does this mean a private marketplace/gallery is available now? Where exactly are the docs?

[josh-hemphill]

@GitMensch It was converted to a discussion thread, which closes the issue it was converted from. microsoft/vsmarketplace#211

[prashantvc]

@gioragutt No! I made it as a discussion https://github.com/microsoft/vsmarketplace/discussions/211

[GitMensch]

... I'm aware of the conversion which was done without any note about the reasons at all.

So there is an upstream discussion now, not even an "issue". Where does this lead this to, concerning this specific feature request with more than 800 user votes?

[prashantvc]

@GitMensch

We are aware this is the top issue for Marketplace and VS Code customers. Converting the issue to discussion in no way undermines the importance of this request.

At marketplace team we have a different journey for feature request to implementation. Right now, we are engaged with the internal teams to better understand the need of private marketplace, and discussion thread fits right to engage the community

I apologies, I should have commented in the issue before converting into a discussion thread

[YaronWittenstein]

I think that being able to publish an extension gradually would be very useful as well. If a new extension update introduces a bug, it'd be better if only 10%, for example, would experience it instead of everyone.

[GitMensch]

@YaronWittenstein I think this discussion is intended to go to microsoft/vsmarketplace#211 or otherwise into that repo, it is not primarily vscode related. As I'm already commenting on that here... While that specific request sounds good at the first look I think it is not needed - people can always install old versions manually and at least vsmarketplace allow you to delete any version, so you can also delete the current one if you see really bad issues and the people already affected would need to downgrade in any case, of course ideally you don't delete the bad version but publish a fixed one ;-) It would be more reasonable to push (or publish as vsix yourself) an "insider" version that people can test, too.

[YaronWittenstein]

@GitMensch thank you!

[AndersHogqvist]

bump!

[pthexton]

@GitMensch

Converting the issue to discussion in no way undermines the importance of this request.

There are 6 participants in that discussion. Out of sight out of mind?

People (presumably within organisations, which is my use case) want this feature. VSCode is great for the ability to write your own productivity extensions, the requirement to publish to the public marketplace if you want to easily share with colleagues / simplify fresh environment setup simply does not make sense where those extensions are literally useless to anybody outside of a given development team / environment.

[StefanMaron]

There are 6 participants in that discussion, meanwhile this request has been starred over 127 thousand times. Out of sight out of mind?

I think the stars belong to the whole repository ;)

But the rest you said, I support 💯

[pthexton]

I think the stars belong to the whole repository ;)

That's a great point, my bad! I've edited accordingly.

[GitMensch]

.. and there are still over 850 implementation votes here - because the people don't want a private marketplace support of the ms market (others exist and do work fine, so there's actual not much need for that "related" issue in the marketplace repo), but a simple way to connect to them... and I already forgot about this - I've created a PR to actually fix that (with open points like the docs) at https://github.com/microsoft/vscode/pull/129764 ...

[pthexton]

.. and there are still over 850 implementation votes here - because the people don't want a private marketplace support of the ms market (others exist and do work fine, so there's actual not much need for that "related" issue in the marketplace repo), but a simple way to connect to them... and I already forgot about this - I've created a PR to actually fix that (with open points like the docs) at #129764 ...

Yeah. I literally just want to be able to publish a private vsix to an internal webserver and have a way of telling vscode "please also look in here", that way any individual projects can use the extensions.json recommendations as normal.

[GitMensch]

Work around:

• setup the server, for example https://github.com/eclipse/openvsx locally
• publish your "local/team" extensions there
• publish every other extension there that you want to use
• adjust package.json to point to this local server (of every vscode installation and again after each vscode update) - or get the referenced PR approved which would remove that need

... but your scenario actually brings up another point, It seems you likely want to be able to reach multiple servers (which would remove the need to publish "every other allowed" extensions to your local server) - that's something reasonable but should be tracked under a new issue (if it doesn't exist) "Support for multiple marketplaces/extension galleries".

[pthexton]

@GitMensch I think my scenario is covered by this part of the OP

and have an ability to specify alternative extension gallery paths

But maybe I'm misunderstanding the minutiae of the vscode extension system and the terms used.