TypeScript 2.4.2 repairs completions and preserves refactoring comments

An editor has to understand code before the programmer finishes writing it. A type annotation ending after its colon is invalid as a completed program, but it is an ordinary point at which to request completion. TypeScript 2.4.2 fixes a language-service failure reported in precisely that situation. The server's response should help complete the program instead of failing while examining its unfinished state.

The npm registry dates 2.4.2 to July 19. Its July 28 release note describes fixes reported against the language services. The linked release milestone identifies three closed issues, covering completion failures and lost documentation during a refactoring. Those are concrete improvements to editing behavior within the existing 2.4 series.

I value TypeScript's editor support because a framework's declarations can make unfamiliar code easier to navigate. That benefit depends on the service continuing to work during incomplete edits. A compiler can reasonably reject unfinished source, while a completion service has to treat it as expected input.

A colon was enough to expose a completion failure

Issue 16610 initially reports an intermittent server error, Cannot read property 'forEach' of undefined. A later July 3 comment supplies a much smaller reproduction using TypeScript 2.4.1. The file contains let x: and the user requests completion immediately after the colon.

The issue's stack trace passes through global-completion filtering and module-export lookup before failing. That establishes where the request broke without requiring an assumption that the source file was otherwise a valid program. The requested operation concerns possible type names at the position where the user is actively writing one.

Incomplete syntax is a defining part of an editor service's workload. A diagnostic about the unfinished declaration can coexist with useful suggestions. Throwing an internal exception instead removes the assistance at exactly the point where the source needs another token. The correction therefore concerns the tool's ability to handle its input, not a change making an incomplete declaration valid JavaScript output.

The issue also shows why a reduced reproduction matters. Its initial report did not have a reliable trigger, while the later example isolates a short editing action. That lets maintainers reason about the state the server receives without reproducing a whole application. The release milestone associates the closed issue with 2.4.2.

Project membership affects imported declarations

Issue 17131 describes another failed completion request under 2.4.1. The error says an inferred project does not contain a particular @types/node document located beneath a dependency's cached type information. Its stack trace goes through project document lookup and dependency-graph maintenance.

The failure is more specific than simply missing a package declaration. The service has encountered a declaration file but cannot obtain it through the project membership path being used. A dependency's type information and the project model have to agree about the documents involved before completion can proceed.

A July 19 maintainer comment says the fix was merged into release-2.4. The release milestone includes the issue. This evidence supports describing the update as a correction to the service's handling of project and declaration-file state. It does not justify claiming that every missing-completion problem in an editor shares this cause.

That distinction helps separate application configuration from an internal tool failure. A project may have incomplete declarations, but a server response stating that its own inferred project cannot supply a referenced document is a different problem. The particular issue needs repair in the service, rather than an invented annotation in the user's source.

Refactoring must retain documentation too

Issue 16622 reports that converting a constructor function and prototype methods into an ES6 class loses a method's JSDoc. The expected result keeps the method's description and parameter comment above the new class method. The actual result preserves the method but removes that comment.

This is meaningful source information, even though removing it need not change the method's runtime behavior. The example documents a speed argument and its intended limits. A refactoring offered as a code-organization change should not silently discard that explanation. The release milestone includes the completed fix.

I regard comment preservation as part of a refactoring's correctness. A developer accepts the transformation to change the code's structure, and the existing documentation still describes the method after that structural change. Requiring the user to reconstruct it would make the automated operation lose information that was already available.

The three fixes illustrate different obligations of the same service. Completion must tolerate partial syntax, its project model must resolve the documents it consults, and a source transformation must preserve relevant comments. TypeScript 2.4.2 addresses those particular failures without adding another language construct. For an application author, the practical change is that the editor can continue helping during an unfinished declaration and can reorganize a documented method without deleting its explanation.