Today we’re happy to announce the availability of the release candidate (RC) of TypeScript 3.1. Our intent with the RC is to gather any and all feedback so that we can ensure our final release is as pleasant as possible.
If you’d like to give it a shot now, you can get the RC through NuGet, or use npm with the following command:
npm install -g typescript@rc
You can also get editor support by
Let’s look at what’s coming in TypeScript 3.1!
Mappable tuple and array types
Mapping over values in a list is one of the most common patterns in programming. As an example, let’s take a look at the following JavaScript code:
function stringifyAll(...elements) {
return elements.map(x => String(x));
}
The
declare function stringifyAll(...elements: unknown[]): Array<string>;
That basically says, “this thing takes any number of elements, and returns an array of
Specifically, the type system doesn’t remember the number of elements user passed in, so our output type doesn’t have a known length either. We can do something like that with overloads:
declare function stringifyAll(...elements: []): string[];
declare function stringifyAll(...elements: [unknown]): [string];
declare function stringifyAll(...elements: [unknown, unknown]): [string, string];
declare function stringifyAll(...elements: [unknown, unknown, unknown]): [string, string, string];
// ... etc
Ugh. And we didn’t even cover taking four elements yet. You end up special-casing all of these possible overloads, and you end up with what we like to call the “death by a thousand overloads” problem. Sure, we could use conditional types instead of overloads, but then you’d have a bunch of nested conditional types.
If only there was a way to uniformly map over each of the types here…
Well, TypeScript already has something that sort of does that. TypeScript has a concept called a mapped object type which can generate new types out of existing ones. For example, given the following
interface Person {
name: string;
age: number;
isHappy: boolean;
}
we might want to convert each property to a string as above:
interface StringyPerson {
name: string;
age: string;
isHappy: string;
}
function stringifyPerson(p: Person) {
const result = {} as StringyPerson;
for (const prop in p) {
result[prop] = String(p[prop]);
}
return result;
}
Though notice that
type Stringify<T> = {
[K in keyof T]: string
};
For those unfamiliar, we read this as “for every property named
and rewrite our function to use that:
function stringifyProps<T>(p: T) {
const result = {} as Stringify<T>;
for (const prop in p) {
result[prop] = String(p[prop]);
}
return result;
}
stringifyProps({ hello: 100, world: true }); // has type `{ hello: string, world: string }`
Seems like we have what we want! However, if we tried changing the type of
declare function stringifyAll<T extends unknown[]>(...elements: T): Stringify<T>;
And then tried calling it on an array or tuple, we’d only get something that’s almost useful prior to TypeScript 3.1. Let’s give it a shot on an older version of TypeScript like 3.0:
let stringyCoordinates = stringifyAll(100, true);
// No errors!
let first: string = stringyCoordinates[0];
let second: string = stringyCoordinates[1];
Looks like our tuple indexes have been mapped correctly! Let’s check the grab the length now and make sure that’s right:
let len: 2 = stringyCoordinates.length
// ~~~
// Type 'string' is not assignable to type '2'.
Uh.
stringyCoordinates.forEach(x => console.log(x));
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Cannot invoke an expression whose type lacks a call signature. Type 'String' has no compatible call signatures.
Huh? What’s causing this gross error message? Well our
While technically consistent in behavior, the majority of our team felt that this use-case should just work. Rather than introduce a new concept for mapping over a tuple, mapped object types now just “do the right thing” when iterating over tuples and arrays. This means that if you’re already using existing mapped types like
Properties on function declarations
In JavaScript, functions are just objects. This means we can tack properties onto them as we please:
export function readFile(path) {
// ...
}
readFile.async = function (path, callback) {
// ...
}
TypeScript’s traditional approach to this has been an extremely versatile construct called
export function readFile() {
// ...
}
export namespace readFile {
export function async() {
// ...
}
}
While perhaps elegant for their time, the construct hasn’t aged well. ECMAScript modules have become the preferred format for organizing new code in the broader TypeScript & JavaScript community, and namespaces are TypeScript-specific. Additionally, namespaces don’t merge with
export const FooComponent => ({ name }) => (
<div>Hello! I am {name}</div>
);
FooComponent.defaultProps = {
name: "(anonymous)",
};
can’t even simply be converted to
export const FooComponent => ({ name }) => (
<div>Hello! I am {name}</div>
);
// Doesn't work!
namespace FooComponent {
export const defaultProps = {
name: "(anonymous)",
};
}
All of this collectively can be frustrating since it makes migrating to TypeScript harder.
Given all of this, we felt that it would be better to make TypeScript a bit “smarter” about these sorts of patterns. In TypeScript 3.1, for any function declaration or
As an added bonus, this functionality in conjunction with TypeScript 3.0’s support for
// TypeScript understands that both are valid:
<FooComponent />
<FooComponent name="Nathan" />
Breaking Changes
Our team always strives to avoid introducing breaking changes, but unfortunately there are some to be aware of for TypeScript 3.1.
Vendor-specific declarations removed
TypeScript 3.1 now generates parts of
Differences in narrowing functions
Using the
function foo(x: unknown | (() => string)) {
if (typeof x === "function") {
let a = x()
}
}
You can read more on the breaking changes section of our wiki.
Going forward
We’re looking forward to hearing about your experience with the RC. As always, keep an eye on our roadmap to get the whole picture of the release as we stabilize. We expect to ship our final release in just a few weeks, so give it a shot now!
