LSP per-resource settings
The language server supports the following settings on a per-resource basis: deno.enable, deno.enablePaths, and deno.codeLens.test.
Deno · Reference · all subjects
cli commands/lsp
28 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
LSP initialization with initializationOptions
When the `initialize` request arrives from the client, the `initializationOptions` will be assumed to be an object that represents the `deno` namespace of options. For example, passing {"enable": true, "unstable": true} will enable Deno with unstable APIs for that LSP instance.
LSP startup via lsp sub-command
The Deno CLI includes a built-in language server that implements the Language Server Protocol. It can be started via the `lsp` sub-command from the command line.
LSP workspace settings
The language server supports the following workspace-level settings: deno.enable, deno.enablePaths, deno.cache, deno.certificateStores, deno.config, deno.importMap, deno.internalDebug, deno.codeLens.implementations, deno.codeLens.references, deno.codeLens.referencesAllFunctions, deno.codeLens.test, deno.suggest.completeFunctionCalls, deno.suggest.names, deno.suggest.paths, deno.suggest.autoImports, deno.suggest.imports.autoDiscover, deno.suggest.imports.hosts, deno.lint, deno.tlsCertificate, deno.unsafelyIgnoreCertificateErrors, and deno.unstable.
LSP configuration request on workspace changes
When the language server receives a `workspace/didChangeConfiguration` notification, it checks if the client has a `workspaceConfiguration` capability. If the client has this capability, the language server sends a `workspace/configuration` request that includes workspace configuration and configuration for all URIs currently tracked.
LSP per-resource configuration on document open
If the client has the `workspaceConfiguration` capability, the language server sends a configuration request for the URI when it receives the `textDocument/didOpen` notification to get resource-specific settings. If the client does not have this capability, the workspace setting applies to all resources.
LSP command: deno.cache
The `deno.cache` command is sent as a resolution code action when there is an un-cached module specifier being imported. It includes an argument containing the resolved specifier as a string to be cached.
LSP command: deno.showReferences
The `deno.showReferences` command is sent on some code lenses to show locations of references. The arguments contain the specifier that is the subject of the command, the start position of the target, and the locations of the references to show.
LSP command: deno.test
The `deno.test` command is sent as part of a test code lens. The client is expected to run a test based on the arguments, which include the specifier the test is contained in and the name of the test to filter tests.
LSP request: deno/cache
The `deno/cache` request instructs Deno to cache a module and all its dependencies. If only a `referrer` is passed, all dependencies for the module specifier are loaded. If values are provided in `uris`, only those URIs are cached. Parameters: interface CacheParams { referrer: TextDocumentIdentifier; uris: TextDocumentIdentifier[]; }
LSP request: deno/performance
The `deno/performance` request returns timing averages for the internal instrumentation of Deno. It does not expect any parameters.
LSP request: deno/reloadImportRegistries
The `deno/reloadImportRegistries` request reloads any cached responses from import registries. It does not expect any parameters.
LSP request: deno/virtualTextDocument
The `deno/virtualTextDocument` request returns a virtual text document from the LSP, which is a read-only document that can be displayed in the client. This allows clients to access documents in the Deno cache, like remote modules and TypeScript library files. The Deno language server encodes internal files under the custom scheme `deno:`. It supports a special URL `deno:/status.md` which provides markdown-formatted status details. Parameters: interface VirtualTextDocumentParams { textDocument: TextDocumentIdentifier; }
LSP request: deno/task
The `deno/task` request returns available deno tasks, see task_runner. It does not expect any parameters.
LSP notification: deno/registryState
The `deno/registryState` notification is sent from the server to the client. When `deno.suggest.imports.autoDiscover` is `true` and an origin for an import is not explicitly set in `deno.suggest.imports.hosts`, the origin is checked and this notification is sent. If `suggestion` is `true`, the client should offer to enable the origin. If `suggestion` is `false`, the client should add it as disabled. Parameters: interface RegistryStatusNotificationParams { origin: string; suggestions: boolean; }
LSP supported language IDs with diagnostics and formatting
The language server supports diagnostics and formatting for: "javascript", "javascriptreact", "jsx" (non-standard, same as javascriptreact), "typescript", "typescriptreact", and "tsx" (non-standard, same as typescriptreact).
LSP supported language IDs with formatting only
The language server supports formatting only for: "json", "jsonc", and "markdown".
LSP testing API capability negotiation
Both client and server should support the experimental `testingApi` capability. The client declares: interface ClientCapabilities { experimental?: { testingApi: boolean; } }. The server declares: interface ServerCapabilities { experimental?: { testingApi: boolean; } }.
LSP testing API behavior when enabled
When a version of Deno that supports the testing API encounters a client which supports the `testingApi` capability, it initializes the code that handles test detection and starts providing the associated notifications. When testing API capabilities are enabled, testing code lenses will no longer be sent to the client.
LSP testing settings: deno.testing.args
The `deno.testing.args` setting is an array of strings which will be provided as arguments when executing tests. This works in the same fashion as the `deno test` subcommand.
LSP testing settings: deno.testing.enable
The `deno.testing.enable` setting is a binary flag that enables or disables the testing server.
LSP test module structure hierarchy
Deno structures tests as: A module can contain n tests. A test can contain n steps. A step can contain n steps.
LSP notification: deno/testModule
The `deno/testModule` notification is sent when a module containing tests is discovered. The notification `kind` is "replace" when tests are discovered statically, and "insert" when tests or steps are discovered at execution time. When a client receives "replace", it can safely replace a test module representation; when "insert" is received, it should recursively add to existing representations. The textDocument.uri is the unique ID for any representation. Parameters: interface TestData { id: string; label: string; steps?: TestData[]; range?: Range; } interface TestModuleParams { textDocument: TextDocumentIdentifier; kind: "insert" | "replace"; label: string; tests: TestData[]; }
LSP notification: deno/testModuleDelete
The `deno/testModuleDelete` notification is issued when a test module is deleted that the server is observing. The client should remove the representation of the test module and all its children tests and test steps. Parameters: interface TestModuleDeleteParams { textDocument: TextDocumentIdentifier; }
LSP notification: deno/testRunProgress states
The `deno/testRunProgress` notification message states are: "enqueued" (test or step enqueued for testing), "skipped" (test or step skipped, occurs when ignore option is true), "started" (test or step started), "passed" (test or step passed), "failed" (error with test harness), "errored" (test or step errored with additional error info in messages property), and "end" (test run ended).
LSP notification: deno/testRunProgress message types
The `deno/testRunProgress` notification supports the following message types: TestEnqueuedStartedSkipped (type: "enqueued" | "started" | "skipped"), TestFailedErrored (type: "failed" | "errored" with messages and optional duration), TestPassed (type: "passed" with optional duration), TestOutput (type: "output" with value and optional test/location), and TestEnd (type: "end"). Parameters: interface TestIdentifier { textDocument: TextDocumentIdentifier; id?: string; stepId?: string; } interface TestMessage { message: MarkupContent; expectedOutput?: string; actualOutput?: string; location?: Location; } interface TestRunProgressParams { id: number; message: TestRunProgressMessage; }
LSP request: deno/testRun
The `deno/testRun` request instructs the language server to perform a set of tests. Currently Deno only supports the "run" kind, with "debug" and "coverage" planned for the future. When there are no test modules or tests included, all discovered test modules and tests are executed. When a test module is included but not test IDs, all tests in that module are included. Parameters: interface TestRunRequestParams { id: number; kind: "run" | "coverage" | "debug"; exclude?: TestIdentifier[]; include?: TestIdentifier[]; } interface EnqueuedTestModule { textDocument: TextDocumentIdentifier; ids: string[]; } interface TestRunResponseParams { enqueued: EnqueuedTestModule[]; }
LSP request: deno/testRunCancel
The `deno/testRunCancel` request allows a client to cancel a currently running test run by providing the test ID. The response is a boolean: `true` if the test is cancelled or `false` if cancellation was not possible. Appropriate test progress notifications are still sent as the test is being cancelled. Parameters: interface TestRunCancelParams { id: number; }