Document options for loading VS Code Extensions from GitLab Package Registry

We want to provide the option to replace/enhance the external marketplace with extensions stored in GitLab Package Registry.

For Microsoft's VS Code distribution, the marketplace is defined in /Applications/Visual Studio Code( - Insiders).app/Contents/Resources/app/product.json

	"extensionsGallery": {
		"nlsBaseUrl": "https://www.vscode-unpkg.net/_lp/",
		"serviceUrl": "https://marketplace.visualstudio.com/_apis/public/gallery",
		"searchUrl": "https://marketplace.visualstudio.com/_apis/public/gallery/searchrelevancy/extensionquery",
		"servicePPEUrl": "https://marketplace.vsallin.net/_apis/public/gallery",
		"cacheUrl": "https://vscode.blob.core.windows.net/gallery/index",
		"itemUrl": "https://marketplace.visualstudio.com/items",
		"publisherUrl": "https://marketplace.visualstudio.com/publishers",
		"resourceUrlTemplate": "https://{publisher}.vscode-unpkg.net/{publisher}/{name}/{version}/{path}",
		"controlUrl": "https://az764295.vo.msecnd.net/extensions/marketplace.json"
	},

Possible solutions

There are more than the ones listed here. All of them would support:

• GitLab authentication - we would need to add support into the fork repository
• "fallback" option of connecting to open-vsx (possibly with an allowlist)

Storing the metadata

There are two types of information we need to store for the extensions:

• extension metadata - this can be either a new entity in our Rails DB, or (more preferably) it would be a GitLab project with Git Repository containing the metadata
• packaged extensions - generally, this can be a HTTPS URL pointing anywhere in the internet, we would use GitLab Package Registry

metadata stored in DB	metadata stored in Git

Active options:

Active options implement the endpoints that Marketplace and open-vsx implements. It's an HTTPS server/api-endpoint providing the extensions.

All active options have a licensing question mark regarding the "fallback" connection to Open-VSX, because it wouldn't be the VS Code app, making the open-vsx API calls, it would be GitLab, and I'm not sure that's allowed.

Option A1: Add GitLab REST API endpoints to serve the extensions

GitLab would provide the facade on top of PackageRegistry to serve VS Code Extensions. This would be useful for our VS Code Server in a Workspace and Desktop VS Code.

Option A2: Add "adapter" active service to our GitLab instance deployment

This would be a small service that would run alongside the GitLab instance. It's similar to option A1, but the adapter logic lives in a different process, not inside the main GitLab project.

@pslaughter shared documentation for how to introduce a service component to GitLab https://docs.gitlab.com/ee/development/adding_service_component.html

We initially considered running this service in the remote dev workspace, but this service would not be accessible to client-only WebIDE.

marketplace facade in the workspace

Passive options

Passive options don't require a server running. VS Code would read the metadata from GitLab instance or Git Repository.

Option P1: Change VS Code implementation to use Git Repo and Package Registry instead of a Marketplace API

Imagine a homebrew-style configuration for extensions.

We would implement custom ExtensionService Which would take a Git repository that would contain a JSON file with a list of all the extensions (or any other metadata format we would see fit).

This solution is IMO more resilient to breaking changes to the Marketplace API. If a new version of VS Code changes the Marketplace API, we can fix the issue when we are upgrading the fork. Other options would require synchronizing a release of the new adapter API and new WebIDE.

This would have the potential to be a more open substitute for open-vsx. We would use it mainly for customer-specific extension repositories, but someone from the community might create a GitHub repo with all the open-source extensions.

Image source file: extension-marketplace-design__2_.excalidraw