TypeScript 2.5.3 repairs refactoring boundaries and generic checking

A refactoring needs to recognize where it applies before it generates any code. A string literal used as a type is not a runtime expression that should be extracted into a function. TypeScript 2.5.3 includes a correction for a language-service suggestion that crossed that boundary. The error was visible in a small tagged-union declaration, where hovering over a literal type offered an irrelevant extraction.

The npm registry records publication on September 26. Its release note identifies fixes for issues reported against 2.5.2 and links the corresponding fixed-issue list. This maintenance set includes work on refactorings and a reported generic-checking performance problem. These changes improve operations already present in the release series rather than announcing another language feature.

I find reliable refactorings useful in framework code where related logic can accumulate in large functions. Their value depends on selecting a valid transformation for the source actually present. An editor offering the wrong action makes the programmer reason about the tool's mistake before returning to the application.

A literal type is not executable code

Issue 18060 shows an Action type with an action property whose type is the literal 'APPEND'. Hovering over that literal produces an extract-function suggestion. The expected behavior is no such suggestion, because the selected text belongs to the type declaration.

The characters resemble a JavaScript string expression, but their role in the syntax tree differs. An extraction that creates a runtime function cannot preserve the meaning of a literal type simply by moving the text into that function. The service needs to classify the selected node before deciding which actions are applicable.

This is a useful example of an editor feature requiring more than a text selection. The same token spelling can participate in different language constructs. A source-aware refactoring should distinguish those constructs instead of applying a transformation wherever a fragment looks familiar. The issue's September fix is included in the release's tracked maintenance work.

An empty catch body is still a valid body

Issue 18541 describes another refactoring failure. A constructor function has a prototype method containing try and an empty catch body. Requesting conversion to an ES6 class produces an internal Debug Failure in the refactoring service instead of the expected edits.

The report's catch clause contains a binding, catch (e) {}. Its empty body is the relevant shape in the reproduction, so this should not be confused with the optional catch-binding syntax added in 2.5. The operation being requested is a class conversion, and the service must preserve the method's existing contents as part of that conversion.

The stack trace runs through node-position assignment and change generation. That identifies an internal source-transformation failure rather than an application exception thrown while executing the method. An empty statement list can still need correct positions and representation when the tool constructs new source. The reported issue was closed with a fix and assigned to the 2.5.3 milestone before the release.

An automated class conversion is attractive because it removes repetitive rewriting. Handling empty bodies is part of making that operation dependable on real code. A program can intentionally ignore an exception, and the refactoring should not require changing that behavior merely to complete a structural edit.

Generic comparison also has an execution cost

Issue 18257 reports a substantial build-time increase after two generic method declarations are added to an interface. The report tests 2.5.2 and a development build. Its reproducer has map-like generic methods, with an implementation returning a more specific class type than the interface return type.

The author reports that noStrictGenericChecks removes the performance problem. That is evidence connecting the reproducer to the stricter comparison path. It is not evidence that disabling the checks is the preferred permanent configuration. The issue was closed through a fix assigned to this maintenance release, so the project can address the checker behavior without redefining the application's intended interface merely to avoid the workload.

The timings in the report describe that author's environment and reproducer. They should not become a claim about every TypeScript build. The important technical point is that a small change to a generic interface can provoke disproportionately expensive comparison work, making type-checker performance a concern even when the application source is not large.

I regard that as a practical obligation of a richer type system. More accurate declarations are useful only if the compiler can process them within a workable development cycle. TypeScript 2.5.3 includes a fix for this reported case alongside the refactoring corrections. The release improves both the applicability of editor actions and the cost of checking particular generic relationships, which are separate parts of the feedback loop an application developer relies on.