TypeScript 2.2 Release Gives JavaScript Developers More of What They Expect

Microsoft has released version 2.2 of the TypeScript language, which focuses on a new object type and improved developer productivity.

For day-to-day use, version 2.2 offers a number of creature comforts that should decrease the time developers spend dealing with simple mistakes. Some features, such as adding missing imports and removing unused declarations, bring the tooling for TypeScript more in parity with other languages. An extremely common mistake in TypeScript/JavaScript is forgetting to use this correctly. The following image, taken from the TypeScript 2.2 announcement post, demonstrates many of the new tooling improvements:

For those using VS Code, the quick fixes are available using VS Code 1.10 and can be accessed by hitting the Ctrl+. key combo.

One very important improvement is the ability to use string indexing in the way JavaScript developers are accustomed to. In JavaScript, an object property can be accessed in a couple ways.

var y = x["prop"];
var z = x.prop;

In this example, y and z have the same value because they both access the property prop of x in two valid ways. Prior to TypeScript 2.2, an object declared with an index signature:

interface Foo {
    // Here is a string index signature:
    [prop: string]: boolean;
}

could only be accessed via the first method above. An experienced JavaScript developer would think nothing of trying to access a property in either of the two methods. Now, version 2.2 allows those natural behaviors to work as expected.

The new object type is one that can be anything except primitive data types. While the new feature is a welcomed one, the additional type has the potential to confuse newcomers. This sentence in the announcement post by TypeScript Program Manager Daniel Rosenwasser requires a careful read to really understand what the new feature can do:

object is distinct from the {} type and Object types ... due to structural compatibility. Because the empty object type ({}) also matches primitives, it couldn’t model APIs like Object.create which truly only expect objects – not primitives. object on the other hand does well here in that it can properly reject being assigned a number.

Note that the font changes in that paragraph make it easier to understand when we're talking about the specific object type and when we're talking about the general concept of objects. Marius Schulz has written a post that goes into more details about the differences among the object types.