Support for github-package hosted extensions

[strazto]

Related to #16

GitHub packages now provides an NPM registry, which is a convenient way for orgs that are already operating within the github org infra to manage private packages.

There's a few caveats to this-

Github Packages are always scoped

From what I can tell, packages on this registry are always scoped, and explicitly map their owner back to the organization / owner.

• Per Cannot install extension which name with scope #16 , this will be a stumbling block as VSCE and vscode don't support scoped extensions, however, per Cannot install extension which name with scope #16 (comment) , it may be possible to work around this by publishing .vsix files with unscoped names to a scoped npm package
  • I haven't tested this yet, there may be some code changes needed to vscode-private-extension-manager to support this, eg, mapping @organization-name/extension-name back to organization-name.extension-name
  • The changes to this codebase would be minimal as most of what this extension does is leverage npm registry API's for discovery and metadata, then discover a file with the vsix extension attacked to a given package and install that.

GitHub only partially supports npm registry APIs

Although it supports:

• querying and installing individual packages by name / scope,

It doesn't support:

• npm's registry search APIs, which is what vscode-private-extension-manager relies on for discovery
• Instead GitHub has it's own API for searching for packages, which likely already has wrappers in their node API client.

There's a few ways to deal with this -

Fetch certain extensions directly

This would apply to

• Extensions in "recommendations" when populating discovery list
• Providing a user command for installing extensions (related: Install private extensions by command #67 )

This should cover a lot of organizational use-cases without requiring this extension to support the GitHub NPM search API.

Add option indicating a registry should use github's api, and handle that for discovering extensions

I think this is probably a bit overkill, but essentially would involve adding first-class support for github's API, if a registry's config indicates it, eg an optional field "host_kind" : "github".

[mak3]

@strazto BTW Do you know if Gitlab Package Registry support necessary npm search API?