Deno 1.43 reduces language-server work and retained document state

An editor's completion request needs an answer while the programmer is still considering the expression. A delay of several seconds changes how useful the feature is, even if the eventual result is correct. Deno 1.43, released May 1, reports reducing completion delays in large projects from roughly six to eight seconds to less than one second. Its release notes show changes in both request handling and the lifetime of document data.

These are Deno's reported observations in the projects it investigated, rather than a general latency guarantee for every workspace. The announcement also reports resolving memory problems in projects that previously exhausted the language server. It does not provide a universal percentage reduction in memory consumption. The specific implementation changes are more useful for understanding why larger workspaces benefit.

I value TypeScript's tooling because the web ecosystem asks developers to coordinate framework conventions and types across many files. Good completion can make that work easier. An editor service that retains too much state or responds after the relevant thought has passed weakens that benefit. This release addresses the implementation supporting the feedback, without claiming a change to the language's type rules.

The server supplies a Deno-specific view of code

The language-server README in the release tag describes an implementation of the Language Server Protocol tailored to Deno. It is integrated into the command-line executable and exposed through the lsp subcommand. This makes the editor service part of the runtime's tooling, with a view of the project appropriate to Deno's module environment.

That relationship matters because a language server has more responsibilities than parsing the file currently visible in the editor. It must connect the file to its dependencies and the project's configuration. A completion result depends on the applicable program state. Keeping that state current has a cost, and retaining every intermediate representation indefinitely would make the cost grow with the project.

The tagged release history names several changes that target those costs. Parsed source retention is limited to open documents. Unused documents are released, and document dependencies receive cleanup. Another fix removes open-document data when a document closes. Together, these changes make the distinction between active editor state and other known project state more explicit.

Knowing a document does not require keeping every representation

The lifetime distinction is important in a large workspace. A service may need to know that a dependency exists without retaining the same parsed representation it keeps for a file the user is actively editing. Releasing an unused representation can reduce memory while leaving the project model capable of obtaining that information again when needed. The release entries identify this retention policy as a concrete target for optimization.

There is a tradeoff in every cache of computed state. Reuse avoids recomputation, but retained objects consume memory and can hold other objects reachable through them. An editor that encounters many files can accumulate data beyond the files the user currently needs. Making release conditions explicit limits that accumulation. This is a state-management problem even when the underlying type checker is behaving correctly.

The release also fixes clearing a script-name cache when a file closes and coalescing pending changes. Those operations concern freshness and coordination. A cache can be both fast to access and wrong for the current document set. Reducing duplicated work has to preserve when the server learns about a project change, so a responsiveness improvement does not merely postpone information the next request requires.

Configuration handling receives a related correction. Missing formatting and lint settings can be inherited from parent scopes. This affects which rules apply to a document, independently of how quickly a request completes. A responsive server still needs the correct scope's configuration to make its answer useful to the editor.

Request boundaries contribute overhead too

Other entries in the release history change how Deno invokes the TypeScript service. One calls serverRequest through V8 instead of through executeScript. Another batches the project-change notification with the next JavaScript request. An additional change avoids passing a structure into op_resolve. These entries identify overhead around the checking operation, alongside changes to the retained data used by it.

That makes the performance story broader than making one type-checking algorithm faster. A completion request passes through software that prepares its inputs, coordinates state, and transfers results. Eliminating avoidable work at those boundaries can improve the time observed by the editor. It can also reduce repeated work that becomes more noticeable as the project model grows.

The published evidence does not assign a separate latency improvement to each entry. It supports a combined result and identifies the changes shipped in the release. Attributing the entire improvement to one patch would go beyond that evidence. The useful conclusion is that Deno addressed request overhead and document lifetime during the same optimization effort.

Runtime startup receives a different cache

The release also introduces V8 code caching for ES and CommonJS module loading. The announcement describes storing compiled bytecode on disk after an initial load and reusing it on later loads. That targets the parsing and compilation work performed when starting an application. It should be distinguished from the language server's policy for retaining parsed documents in memory.

Both involve reuse, but they have different consumers and lifetimes. The editor needs a responsive, current view of changing source. Application startup can reuse compiled work for module loading. A favorable result in one does not establish a favorable result in the other. Keeping those mechanisms separate makes the release's performance claims easier to interpret.

I regard the document-lifetime work as particularly relevant to TypeScript development at scale. Faster completion matters, but avoiding an out-of-memory failure is a separate improvement in whether the editor service remains usable. Deno's notes identify concrete places where state is released and requests are coordinated. Those details provide a more informative account of the release than treating its reported completion time as a property of every TypeScript project.