Why is GitHub Copilot Published on marketplace???

[Alexmhack]

Hi maintainers,

This may not be the right place to raise this issue but I am confused on why is GitHub Copilot extension published on VS code marketplace even though it uses VS Code Proposed APIs. Docs clearly state that extensions using these APIs cannot be published.

I am trying to publish an extension which uses Inline completion provider APIs from the new proposed APIs but cannot do so due to the strict policy imposed on the developers but it isn't the case for the Microsoft's VS code editor's "GitHub Copilot" extension owned by Microsoft's GitHub??

We can share extensions which use proposed APIs but users still need to install vscode insiders and configure runtime arguments too which is a very bad and hectic user experience.

Please provide a way to do this in the same way that GitHub Copilot extension does without having to install VS code insiders or configuring runtime arguments or any other hassles, simple click install and start using Copilot code suggestions.

[gregvanl]

Moving to vscode product repo.

[amir-halloul]

I would also like to know why copilot gets to have this special treatment and bypass the proposed API system.

[danechitoaie]

No problem that Copilot gets to use this API. But we want to be able to use it too for our extension.

[ShanConn]

it's widely known that msft/github/vscode are utilizing the product to unfairly compete with other cloud platforms.

[ShanConn]

I would also like to know why copilot gets to have this special treatment and bypass the proposed API system.

because neither msft nor github are really invested into developer's best interests. github+azure+vscode is a very clear case of conflict of interest.

[isidorn]

Hi, Isidor here from the VS Code team 👋
Thank you very much for your feedback, we really appreciate it.

At Visual Studio Code, we take Extension API compatibility very seriously. We always avoid breaking API changes, and extension authors could expect published extensions to continue to work. However, this puts great limitation on us: once we introduce an API, we cannot easily change it any more.
Proposed API solves the problem for us. Proposed API is a set of unstable API that are implemented in VS Code but not exposed to the public as stable API does.

One of the biggest reasons why VS Code is a high quality product is the fact that we ourselves self host on it and constantly provide feedback to each other. We take the same approach with API, when adding new proposed API we need an extension partner that is willing to constantly provide valuable feedback to an ever changing proposed api us so we can make sure that the final API reaches the high quality level we have accustomed the extension authors to.
The extension partner sacrifices a lot of time and effort in order to help us design and identify the shape of the proposed API. In return for all this time and effort and to get even more feedback on a feature and its corresponding API we exceptionally allow the extension partner to publish the extension to the marketplace.
For one proposed API we usually work with 1-2 extension partners because our small team cannot manage many of such relationships. They involve regular meetings, agreement to immediately react to a change in the API, since we never want to have broken extensions in the MP.

We are in the process of restricting this even more by allowing extension partners to only use the proposed API they helped us design. Eventually, Proposed API finds their way into the stable API and becomes available for all extensions.

GitHub Copilot uses the inlayCompletions proposed API. We plan to finalise this API in February. You can already develop your extensions with this API usage in mind, and you will be able to publish the extension to the marketplace in February. One corner case is the getInlineCompletionItemController which we do not plan to finalise, this is a work around which we plan to remove in the future and is not related to the core functionality of the inline completions.

Please try using this API and provide feedback, so we can improve it even more before we do the finalisation.

[danechitoaie]

Hi @isidorn
This makes sense and is understandable. Thanks for providing more info about this.
What would be great is if possible to still have some kind of "allowlist" where we understand and agree that we use some APIs that are not stable and that we take the responsibility of needing to update things as they may break from one day to the other.

In some cases the risk of adopting unstable APIs is low, for example in our case we develop an internal extension to be used only by a limited set of users, we do publish it on the market place as we want our users to get full VSC extension experience (easy install and updates) but extension can only be used by internal users behind auth. So in this case it would be no problem if we use experimental API, as we would update it anytime needed. Even better if there's some way to subscribe to these changes somehow. Just to give an example of a use-case where using unstable API would be acceptable.

Now, since this will be public in February that's great news and think we can wait until then with publishing the extension and we will try to manually distribute it among our internal users (which is a pain, but great news that it's only needed until February)

Thanks.

[jeanp413]

Another idea:
Now that vscode supports pre-release version of extensions, how about allowing "proposed" APIs on them? I think this fits perfectly as a use case for pre-release extensions.

[danechitoaie]

@jeanp413 that's a great idea.

[ghost]

What if I want to use a proposed API as a developer-only feature? (In this case, I am polling onDidWriteTerminalData output to ensure a REPL is working correctly. I have zero interest in users gaining proposed API access, just developers and CI workflow)

[danechitoaie]

We plan to finalise this API in February.

@isidorn Any idea when this will be available in VSC without the flag? We have an internal extension (only for our company employees) that uses this API and enabling this flag is the number one issue everyone is facing and having difficulties when trying to use the extension.

In our case it's ok if you guys make breaking changes as we can update and fix immediately. So for us is more problematic to explain to every user every time how they need to enable this than to have a normal way of using it and commit to fixing any breaking change immediately.

[isidorn]

@danechitoaie thanks for the ping.
We have started on the finalisation process of this API a couple of weeks ago. There is more work than I initially thought so this will not get finished this milestone. We will continue working on the finalisation process in the next milestone with the goal of having it finalised in April.
Progress is tracked in this issue #124024

[isidorn]

We have finalised the inline completions API.
More details can be found here #124024 (comment)

Please try it out and let us know how it works for your extensions. Thanks!