Deno language server to-do list

[kitsonk]

Post the initial implementation of the language server, there are quite a few other features that need to be added as well as some "tech debt" from the initial implementation. We might want to break some of these off to individual issues, but it is good enough for now to have a "master" issue for tracking purposes.

Language Service Features

These are server capabilities provided by the language server protocol, which various editors can take advantage of. Most of these features are exposed here in visual studio code for TypeScript/JavaScript and provide a high level structure of how to take information from the tsc compiler isolate and bring it into Rust and send it back over the language server client. Specifically, the DefinitionProvider is a good model of how to add a feature. Looking at the cli/lsp/mod.rs for the GotoDefinition handling demonstrates calling into tsc and dealing with a response back, converting it to a valid lsp response.

• TypeDefinitionProvider:star: (feat(lsp): add type definition provider #12789)
• WorkspaceSymbolProvider (feat(lsp): add workspace symbol provider #12787)
• Workspace Folders (multiple roots per workspace) (feat: support workspace folders configuration #10488)
• Completion Provider (this will be the most complex one, because we also need to enrich the response back from tsc) an mvp exists (feat(lsp): basic support for textDocument/completion #8651), but we likely want to enhance it.
  • Enable include_completions_with_insert_text (in consequence enabling include_automatic_optional_chain_completions and include_completions_for_module_exports) this is largely fixed
  • Registry completions (feat(lsp): add registry import auto-complete #9934)
• SignatureHelpProvider ⭐ (feat(lsp): Implement textDocument/signatureHelp #9330)
• CodeActionProvider ⭐
  • QuickFix
  • deno cache
• ImplementationProvider ⭐ (feat(lsp): Add textDocument/implementation #9071)
• CodeLensProvider (feat(lsp): add references code lens #9316)
  • References (feat(lsp): add references code lens #9316)
  • Implementations
  • Deno specific code lenses, like tests? (feat(lsp): add test code lens #10874)
• RenameProvider (feat(lsp): Implement textDocument/rename #8910)
• SelectionRangeProvider (feat(lsp): Implement textDocument/selectionRange #9845)
• FoldingRangeProvider (feat(lsp): Implement textDocument/foldingRange #9900)
• CallHierarchyProvider (feat(lsp): Implement textDocument/prepareCallHierarchy #10061)
• SemanticTokensProvider (feat(lsp): Implement textDocument/semanticTokens/full #10233)
• DocumentSymbolProvider (feat(lsp): Implement textDocument/documentSymbol #9981)
• DocumentLinkProvider - vscode only implements this for tsconfig.json, we should consider it for deno.jsonc
• DocumentRangeFormattingProvider (maybe)
• DocumentOnTypeFormattingProvider (maybe)
• SemanticHighlighting - vscode does not implement this for typescript, semantic tokens instead
• ColorProvider vscode does not implement this for typescript
• ExecuteCommandProvider there is nothing to implement here
• OnTypeRenameProvider vscode does not implement this for typescript
• DeclarationProvider ⭐ vscode does not implement this for typescript

Extension Configuration Options

There are several configuration/settings that are currently not respected by the language server, but should be.

• cachePath - allow the DENO_DIR to be set in the configuration for the workspace allowing the default to be overridden and not need to setup an environment variable to change it.
• enable - this is only partially respected at the moment, for diagnostics, but other requests are duplicating values when enabled (fix(lsp): respect enable flag for requests #8850)
• unstable - needs to configure the tsc isolate with a new set of libs which include the unstable ones (feat(lsp): support the unstable setting #8851)
• importMap - the language server state should own the value and be passed when resolving modules (feat(lsp): support import maps #8683)
• config - needs to change the config to the isolate, since --config is a CLI opt in, it should only be resolved when set and passed to the tsc isolate (feat(lsp): support specifying a tsconfig file #8926)

Additional Items

• The unit tests are quite spotty, and far from exhaustive, we need more unit tests
• There is a basic integration test infrastructure, but we could use more integration tests
• We need to provide typeahead completion for module registry via the language server, like the version 2 of the extension was able to do, but not have any of that in the extension, do it all from the language server.
• The current branch only provides access to modules that are already in the DENO_DIR. We can in theory instruct Deno to go fetch additional remote modules, but that comes with risks, because people will be typing out modules in a lot of cases and we don't want to DDOS registries with bad modules names. So we need to figure out when is it ok to fetch modules, if we do it automatically, or not.
• Deal with unicode and JavaScript properly. Investigate using swc's SourceMap to hold the in memory documents.
• Consider using swc's jsdoc crate when handling JSDoc between TypeScript and the language service.
• deno_lint should generate an unused tag as part of its diagnostic structure to flag unreachable code.
• We can spawn off diagnostics for things like deno_lint or reformatting a document to a seperate thread, but we don't allow isolates to be sent to other threads, in order not to have to deal with managing the lock, but it would be good to have a dedicated thread for getting diagnostics from the compiler isolate as to not lock the main loop of the language service.
• Re-work the static built assets... currently the language server is re-lining all the static type definition files... we were able to remove most of them from the Rust side during the build process, as they were actually present in the tsc snapshot and not needed anywhere else (except for a limit set for deno types). Now we need to have them all in the lsp in Rust to provide them on a goto definition situation.

[hrsh7th]

Hi. How about dealing with deps.ts as a first-class dependency definition in deno lsp (not deno runtime)?

I have written golang recently and it was a great development experience.
I think it's due to only gopls.

I believe it makes a great development experience and consistency if deno lsp suggests completion by deps.ts and applies auto-import as by confirming it.

[hrsh7th]

May I send PR for textDocument/rename?

[bartlomieju]

Hi. How about dealing with deps.ts as a first-class dependency definition in deno lsp (not deno runtime)?

I have written golang recently and it was a great development experience.
I think it's due to only gopls.

I believe it makes a great development experience and consistency if deno lsp suggests completion by deps.ts and applies auto-import as by confirming it.

There's still quite a lot we need to work on achieve parity with old version of vscode-deno before we can work on new features.

May I send PR for textDocument/rename?

Of course!

[hrsh7th]

I will tackle to support completionItem/resolve.

[uki00a]

I'll try to implement textDocument/signatureHelp (SignatureHelpProvider).

[hrsh7th]

microsoft/TypeScript#39459

[David-Else]

Hi, the LSP is not currently providing documentation for the completion, is this on the Language Service Features list? hrsh7th/nvim-compe#187

[jeanp413]

Hi I would like to work on the SelectionRangeProvider

[jeanp413]

I'll work on the FoldingRangeProvider

[jeanp413]

I'll work on the DocumentSymbolProvider

[jeanp413]

I'll tackle CallHierarchyProvider

[jeanp413]

I'll tackle SemanticTokensProvider

[kitsonk]

@jeanp413 thank you, I will get to dealing with your other contributions early next week, just needed to work on something else this week.

[bartlomieju]

@kitsonk it appears to me that this issue is done at this point. Can we close it now?

[kitsonk]

Yeah, we can track other bits in individual issues.