mirror of
https://github.com/denoland/deno.git
synced 2025-02-07 23:06:50 -05:00
c31b670323
This makes it so imports of ambient modules (e.g. `$app/environment` in svelte, any virtual module in vite, or other module provided by a bundler) don't error in the LSP. The way this works is that when we request diagnostics from TSC, we also respond with the list of ambient modules. Then, in the diagnostics code, we save diagnostics (produced by deno) that may be invalidated as an ambient module and wait to publish the diagnostics until we've received the ambient modules from TSC. The actual ambient modules you get from TSC can contain globs, e.g. `*.css`. So when we get new ambient modules, we compile them all into a regex and check erroring imports against that regex. Ambient modules should change rarely, so in most cases we should be using a pre-compiled regex, which executes in linear time (wrt the specifier length). TODO: - Ideally we should only publish once, right now we publish with the filtered specifiers and then the TSC ones - deno check (#27633) |
||
|---|---|---|
| .. | ||
| testing | ||
| analysis.rs | ||
| cache.rs | ||
| capabilities.rs | ||
| client.rs | ||
| code_lens.rs | ||
| completions.rs | ||
| config.rs | ||
| diagnostics.rs | ||
| documents.rs | ||
| jsr.rs | ||
| language_server.rs | ||
| logging.rs | ||
| lsp_custom.rs | ||
| mod.rs | ||
| npm.rs | ||
| parent_process_checker.rs | ||
| path_to_regex.rs | ||
| performance.rs | ||
| README.md | ||
| refactor.rs | ||
| registries.rs | ||
| repl.rs | ||
| resolver.rs | ||
| search.rs | ||
| semantic_tokens.rs | ||
| text.rs | ||
| tsc.rs | ||
| urls.rs | ||
Deno Language Server
The Deno Language Server provides a server implementation of the
Language Server Protocol
which is specifically tailored to provide a Deno view of code. It is
integrated into the command line and can be started via the lsp sub-command.
This documentation has been moved to the Deno manual.