@github/copilot-language-server 1.265.0 → 1.267.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1 +1,311 @@
1
- **Important:** If you are looking to use GitHub Copilot, please see [copilot.github.com](https://copilot.github.com) for more information. This package provides an internal library and is not intended for public use.
1
+ # @github/copilot-language-server
2
+
3
+ The Copilot Language Server enables any editor or IDE to integrate with GitHub
4
+ Copilot via [the language server protocol](https://microsoft.github.io/language-server-protocol/).
5
+
6
+ **[GitHub Copilot](https://github.com/features/copilot)** is an AI pair programmer tool that helps you write code faster and smarter.
7
+
8
+ **Sign up for [GitHub Copilot Free](https://github.com/settings/copilot)!**
9
+
10
+ Please see [terms of use for GitHub Copilot](https://docs.github.com/en/site-policy/github-terms/github-terms-for-additional-products-and-features#github-copilot)
11
+
12
+ ## Getting Started
13
+
14
+ To integrate with the Copilot Language Server, download the latest release from npm:
15
+
16
+ ```sh
17
+ npm install @github/copilot-language-server
18
+ ```
19
+
20
+ To run the language server, platform-specific binaries are available in the `native` directory of the npm package. For
21
+ example, for macOS on arm64:
22
+
23
+ ```sh
24
+ ./node_modules/@github/copilot-language-server/native/darwin-arm64/copilot-language-server --version
25
+ ```
26
+
27
+ Or you can use [Node.js](https://nodejs.org/en/download/) version 20.x or later:
28
+
29
+ ```sh
30
+ node ./node_modules/@github/copilot-language-server/dist/language-server.js --version
31
+ ```
32
+
33
+ If using the `language-server.js` distribution, it is necessary to retain the entire `dist` directory contents.
34
+
35
+ Communication with the language server typically happens over stdio with `--stdio`. The `language-server.js`
36
+ distribution additionally supports Node IPC with `--node-ipc`.
37
+
38
+ ## Communication Protocol
39
+
40
+ The [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) (LSP) is used to communicate with
41
+ the client. The base protocol is [JSON-RPC 2.0 with additional
42
+ headers](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#baseProtocol).
43
+
44
+ The Copilot Language Server attempts to follow the LSP spec as closely as possible, but many custom messages are
45
+ employed to support the unique features of Copilot.
46
+
47
+ ## Initialization
48
+
49
+ Per the LSP spec, the client is expected to send a
50
+ [`initialize`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialize)
51
+ request to the language server as a first message. Example parameters:
52
+
53
+ ```json
54
+ {
55
+ "processId": 1234,
56
+ "workspaceFolders": [
57
+ {
58
+ "uri": "file:///home/user/project"
59
+ }
60
+ ],
61
+ "capabilities": {
62
+ "workspace": {"workspaceFolders": true}
63
+ },
64
+ "initializationOptions": {
65
+ "editorInfo": {
66
+ "name": "GNU ed",
67
+ "version": "1.19"
68
+ },
69
+ "editorPluginInfo": {
70
+ "name": "GitHub Copilot for ed",
71
+ "version": "1.0.0"
72
+ }
73
+ }
74
+ }
75
+ ```
76
+
77
+ After receiving the response to `initialize`, the second message the client must send is an
78
+ [`initialized`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialized)
79
+ notification.
80
+
81
+ ## Configuration Management
82
+
83
+ After initialization, clients should send a
84
+ [`workspace/didChangeConfiguration`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_didChangeConfiguration)
85
+ notification to inform the language server about the initial configuration, and again each time the configuration
86
+ changes. Example parameters:
87
+
88
+ ```json
89
+ {
90
+ "settings": {
91
+ "http": {
92
+ "proxy": "http://localhost:8888",
93
+ "proxyStrictSSL": true,
94
+ "proxyKerberosServicePrincipal": "spn"
95
+ },
96
+ "telemetry": {
97
+ "telemetryLevel": "all"
98
+ },
99
+ "github-enterprise": {
100
+ "uri": "https://example.ghe.com"
101
+ }
102
+ }
103
+ }
104
+ ```
105
+
106
+ Pull based configuration on
107
+ [`workspace/configuration`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_configuration)
108
+ is also supported.
109
+
110
+ ## Workspace Folders Synchronization
111
+
112
+ Workspace folders are optional but highly recommended as they greatly improve the quality of suggestions. See the LSP spec for
113
+ [`workspace/didChangeWorkspaceFolders`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_didChangeWorkspaceFolders).
114
+
115
+ ## Text Document Synchronization
116
+
117
+ Per the LSP spec for
118
+ [text document synchronization](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_synchronization),
119
+ support for `textDocument/didOpen`, `textDocument/didChange`, and `textDocument/didClose` is required, using incremental
120
+ sync.
121
+
122
+ ## Text Document Focusing
123
+
124
+ Additionally a custom `textDocument/didFocus` notification should be sent when the client focuses another document
125
+ (e.g., changing tabs). Example parameters:
126
+
127
+ ```json
128
+ {
129
+ "textDocument": {
130
+ "uri": "file:///path/to/file"
131
+ }
132
+ }
133
+ ```
134
+
135
+ If no document is focused, a request with no parameters (`{}`) may be sent.
136
+
137
+ ## Status Notification
138
+
139
+ The status is sent to the client as a `didChangeStatus` notification. Typically this would be conveyed to the user in a
140
+ status bar icon or other UI affordance.
141
+
142
+ Notification includes the following fields:
143
+
144
+ - `message` - a string describing the status (can be empty)
145
+ - `kind` - status of the language server:
146
+ - `'Normal'` - When everything is working normally.
147
+ - `'Error'` - When not authorized and authenticated.
148
+ - `'Warning'` - When there is a temporary issue, such as a failed HTTP request.
149
+ - `'Inactive'` - When the current file is ignored due to file size or content exclusions.
150
+
151
+ ## Authentication
152
+
153
+ To sign in, call `signIn`. This will return a response like the following:
154
+
155
+ ```json
156
+ {
157
+ "userCode": "ABCD-EFGH",
158
+ "command": {
159
+ "command": "github.copilot.finishDeviceFlow",
160
+ "arguments": [],
161
+ "title": "Sign in"
162
+ }
163
+ }
164
+ ```
165
+
166
+ Instruct the user to copy the `userCode` to their clipboard (and/or copy it programmatically). When the user is ready, invoke
167
+ [`workspace/executeCommand`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_executeCommand)
168
+ to execute the `command`. This will open a browser window that walks the user through the authentication process.
169
+ Shortly (up to 10 seconds) after the user finishes signing in, you should see a status notification reflecting the new
170
+ state.
171
+
172
+ If available, the language server will use
173
+ [`window/showDocument`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#window_showDocument)
174
+ to open the URL. Otherwise, it will attempt to open the URL natively (e.g., with `/usr/bin/open` on macOS).
175
+
176
+ To sign out, call `signOut`.
177
+
178
+ ## Inline Completions
179
+
180
+ The [`textDocument/inlineCompletion`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#textDocument_inlineCompletion)
181
+ request from the draft version of the next LSP spec is used to retrieve inline ("ghost text") completions, with some
182
+ non-standard additions (`textDocument.version` and `formattingOptions`) to the parameters:
183
+
184
+ ```json
185
+ {
186
+ "textDocument": {
187
+ "uri": "file:///path/to/file",
188
+ "version": 0
189
+ },
190
+ "position": {"line": 1, "character": 2},
191
+ "context": {
192
+ "triggerKind": 2
193
+ },
194
+ "formattingOptions": {
195
+ "tabSize": 4,
196
+ "insertSpaces": true
197
+ }
198
+ }
199
+ ```
200
+
201
+ The result is an object containing an `items` array.
202
+
203
+ ```json
204
+ {
205
+ "items": [
206
+ {
207
+ "insertText": "a helpful suggestion",
208
+ "range": {
209
+ "start": {"line": 1, "character": 0},
210
+ "end": {"line": 1, "character": 2}
211
+ },
212
+ "command": {
213
+ "command": "github.copilot.didAcceptCompletionItem",
214
+ "arguments": ["some id"]
215
+ }
216
+ }
217
+ ]
218
+ }
219
+ ```
220
+
221
+ Newlines in `insertText` should be normalized as is appropriate for the editor before inserting into the document.
222
+
223
+ The `command` field, per the LSP spec, is called via
224
+ [`workspace/executeCommand`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_executeCommand)
225
+ *after* the user accepts the completion. Copilot uses this for acceptance telemetry.
226
+
227
+ The LSP spec does not provide an event for showing the completion, so a custom `textDocument/didShowCompletion` is used.
228
+ Call it with an `item` parameter containing the full completion item:
229
+
230
+ ```json
231
+ {
232
+ "item": {
233
+ "insertText": "a helpful suggestion",
234
+ "range": {
235
+ "start": {"line": 1, "character": 0},
236
+ "end": {"line": 1, "character": 2}
237
+ },
238
+ "command": {
239
+ "command": "github.copilot.didAcceptCompletionItem",
240
+ "arguments": ["some id"]
241
+ }
242
+ }
243
+ }
244
+ ```
245
+
246
+ Similarly, for partial acceptance, send a `textDocument/didPartiallyAcceptCompletion` notification with the full
247
+ item, plus the length (in UTF-16 codepoints) of the completion that was accepted:
248
+
249
+ ```json
250
+ {
251
+ "item": {
252
+ "insertText": "a helpful suggestion",
253
+ "range": {
254
+ "start": {"line": 1, "character": 0},
255
+ "end": {"line": 1, "character": 2}
256
+ },
257
+ "command": {
258
+ "command": "github.copilot.didAcceptCompletionItem",
259
+ "arguments": ["some id"]
260
+ }
261
+ },
262
+ "acceptedLength": 9
263
+ }
264
+ ```
265
+
266
+ Note that the `acceptedLength` includes everything from the start of `insertText` to the end of the accepted text. It is
267
+ *not* the length of the accepted text itself.
268
+
269
+ ## Panel Completions
270
+
271
+ Panel completions are used for "Open Copilot" style completions. They are similar to inline completions, but are shown
272
+ in a separate panel. They are retrieved using the custom `textDocument/copilotPanelCompletion` request, which has
273
+ parameters closely modeled after `textDocument/inlineCompletion`:
274
+
275
+ ```json
276
+ {
277
+ "textDocument": {
278
+ "uri": "file:///path/to/file",
279
+ "version": 0
280
+ },
281
+ "position": {"line": 1, "character": 2},
282
+ "partialResultToken": "some token"
283
+ }
284
+ ```
285
+
286
+ If provided, the `partialResultToken` is used to stream
287
+ [partial results](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#partialResults)
288
+ back to the client. Both the return type and the partial result type are the same as for inline completions: an object
289
+ containing an `items` array. These items have the same `command` that must be invoked with `workspace/executeCommand`
290
+ after accepting to trigger acceptance telemetry. Partial acceptance and shown events are not supported here.
291
+
292
+ ## Cancellation
293
+
294
+ `textDocument/inlineCompletion` supports cancel-previous strategy for cancellation: If you send new completions
295
+ request, the previous request is cancelled.
296
+
297
+ Additionally the LSP `$/cancelRequest` method is supported to cancel any request. It is strongly encouraged to eagerly
298
+ cancel completion requests as soon as possible.
299
+
300
+ ## Logs
301
+
302
+ Logs are sent to the client as
303
+ [`window/logMessage`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#window_logMessage)
304
+ notifications.
305
+
306
+ ## Messages
307
+
308
+ The client may be sent
309
+ [`window/showMessageRequest`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#window_showMessage)
310
+ requests. Support for these messages is essential as they are used for important notifications including account and
311
+ billing.