Issue 1:
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⭐ (#12789)

WorkspaceSymbolProvider (#12787)

Workspace Folders (multiple roots per workspace) (#10488)

Completion Provider (this will be the most complex one, because we also need to enrich the response back from tsc) an mvp exists (#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 (#9934)

SignatureHelpProvider ⭐ (#9330)

CodeActionProvider ⭐

QuickFix

deno cache

ImplementationProvider ⭐ (#9071)

CodeLensProvider (#9316)

References (#9316)

Implementations

Deno specific code lenses, like tests? (#10874)

RenameProvider (#8910)

SelectionRangeProvider (#9845)

FoldingRangeProvider (#9900)

CallHierarchyProvider (#10061)

SemanticTokensProvider (#10233)

DocumentSymbolProvider (#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 (#8850)

unstable - needs to configure the tsc isolate with a new set of libs which include the unstable ones (#8851)

importMap - the language server state should own the value and be passed when resolving modules (#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 (#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.

Issue 2:
Add sync and async APIs to the Deno namespace which allow to acquire (advisory) file-system locks. The API could look something like this:

interface LockOptions {
mode: "shared" | "exclusive";
}

interface Deno {
// ...

flock: (pid: number, options: LockOptions) => Promise<void>;
fsyncLock: (pid: number, options: LockOptions) => void;

funlock: (pid: number) => Promise<void>;
fsyncUnlock: (pid: number) => void;

// plus potentially something to check if a file lock can
// be acquired.
fcheckLock: (pid: number, options: LockOptions) => Promise<boolean>;
fsyncCheckLock: (pid: number, options: LockOptions) => boolean;

// ...
}

One possible good candidate for implementing those on the Rust side would be the fs3 crate.

The motivation for having these APIs is that they would enable synchronization between different processes which access the same file. In particular, this functionality would enable the https://deno.land/x/sqlite library to provide the complete set of persistence guarantees native SQLite offers.