TypeScript 2.1.5 maintains the compiler and its editor service

The TypeScript version in a project describes more than the executable that emits JavaScript. The package also supplies an editor service and declaration files used to describe standard APIs. A maintenance release therefore updates several pieces of the programming environment together. TypeScript 2.1.5 is a useful point to examine that relationship after December's addition of property-oriented type operators.

The npm registry records publication of 2.1.5 on January 12, 2017. The release announcement describes it as fixes for bugs reported against 2.1.4. It links a fixed-issue query and offers npm, NuGet, and the Visual Studio 2015 plugin as distribution routes. It does not announce another set of language constructs.

I find TypeScript's integration with web development tools more compelling than its syntax alone. Useful completions and dependable diagnostics reduce the effort of navigating framework APIs. Keeping that assistance consistent with the compiler that checks the project is part of evaluating a maintenance version.

The package has several entry points

The published package metadata maps tsc to bin/tsc and tsserver to bin/tsserver. The 2.1.5 package archive contains small launchers that load lib/tsc.js and lib/tsserver.js respectively. It also names lib/typescript.js as the package's main library entry and lib/typescript.d.ts as its typing declaration.

These entries support different consumers of the same release. A command-line build invokes the compiler, while an editor integration can use the server. A tool importing TypeScript as a library has another entry point. Installing the package makes those files available, but the package metadata alone does not establish which one an external editor has chosen to execute.

That distinction explains a possible source of disagreement between editing and building. If an editor uses a different installation, its results need not describe the exact compiler package used by the build. This is a consequence of selecting different tools, not evidence that every diagnostic difference is an editor defect. The release's distribution routes make version selection a concrete part of the environment.

The package also declares a minimum Node version of 4.2.0. That requirement concerns the host executing the TypeScript tools. It is separate from the JavaScript target selected for an application's output. The compiler's own host requirements do not determine which browser APIs exist when the compiled application runs.

Its included README distinguishes the stable installation from nightly builds selected through typescript@next. The maintenance release belongs to the stable series. Choosing the nightly channel is a separate decision about which compiler development state a project consumes, even though both arrive through npm.

Standard utilities travel with the checker

The archive's lib.es5.d.ts contains Partial, Readonly, Pick, and Record. These are the utility types introduced in the TypeScript 2.1 release. Their definitions use mapped types and, where appropriate, keyof and indexed access. They are declarations included in the package, not independent runtime libraries installed by an application.

For example, Partial maps each key in an existing type to an optional property with its original value type. Pick maps a constrained selection of keys to the corresponding property types. The declaration file therefore depends on the compiler understanding the type syntax it uses. Shipping the definitions with the tools keeps that relationship visible in a versioned artifact.

The difference from runtime code matters when interpreting what an update supplies. An application using Partial does not receive a new JavaScript function that constructs partial objects. The alias changes how the checker describes permitted values. The implementation accepting those values still determines whether an omitted field means leave it unchanged, use a default, or perform some other application-specific action.

The 2.1 defaults remain relevant

The December announcement also permits importing an installed package without declarations and treating it as any, unless noImplicitAny requests a diagnostic. That is existing 2.1 behavior, not a new feature attributed to 2.1.5. It affects how much confidence a developer can draw from an apparently successful compiler run.

A call through any supplies less static information than one through a declaration that relates its arguments and result. Updating the compiler does not invent declarations for every dependency. The package can correct implementation defects while a project's chosen configuration still determines which missing information becomes visible as an error.

I regard that as a reason to distinguish a compiler correction from a stronger checking policy. Both can help an application, but they change different things. The 2.1.5 announcement offers fixes within the existing release series, and the package retains the declarations and entry points needed to use that series in builds and editors. The useful maintenance unit is the versioned tool package together with the configuration and dependency descriptions it consumes.