Skip to content

Provide full type definitions #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
LinqLover opened this issue Mar 15, 2025 · 3 comments
Open

Provide full type definitions #9

LinqLover opened this issue Mar 15, 2025 · 3 comments

Comments

@LinqLover
Copy link

E.g., I'd like to know what telemetry levels there are or what possible messages are sent via didChangeStatus`.

An exhaustive overview such as type definition file would help me catch all the cases without too much experimenting.

@tpope
Copy link

tpope commented Mar 16, 2025

I'd like to do this. It would take some engineering work on our end.

E.g., I'd like to know what telemetry levels there are

Workspace configuration would be a step beyond basic protocol types. Informally you can often look at what VS Code does, either by poking around in its settings UI or diving into its source. For example, here are the types that our http.proxy* settings are based on: https://github.com/microsoft/vscode/blob/ad05d15e38162b24a829692306d595fb61dd83af/src/vs/platform/request/common/request.ts#L197-L266

For telemetry.telemetryLevel, if you set the value to "off", it will prevent the SDK from directly sending client-side telemetry (e.g., "the user accepted a completion"). But if you care about the data that is collected rather than the means of collecting it, you would be better served by adjusting the "Allow GitHub to..." policies found in Copilot settings. I wouldn't recommend making this setting directly available to users for that reason. Instead, you could direct them to this documentation.

In fact, I might yank those 3 lines of JSON from the README because I think they're more misleading than helpful.

or what possible messages are sent via didChangeStatus.

The type here would be message?: string; as these messages are arbitrary text intended for directly displaying to the user. They are subject to change and may include dynamic content (e.g., an error message sent from the server). Or to put it another way, the API does not currently provide the information you are looking for. It's not ideal, but for now, I would advise allowing the user to sign in again in case of any Error.

@LinqLover
Copy link
Author

Thanks for the detailed reply! I will check out the VS Code references soon. I really love this SDK!

Regarding status messages, I have also noticed that the server is emitting undocumented statusNotification messages with additional details busy and status. If these could be documented as well, that would be great.

@tpope
Copy link

tpope commented Mar 19, 2025

Regarding status messages, I have also noticed that the server is emitting undocumented statusNotification messages with additional details busy and status. If these could be documented as well, that would be great.

This is not part of the API, and will be cleaned up eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants