TypeScript 3.0

TypeScript 3.0 also introduces a new mode for tsc, the —build flag, that works hand-in-hand with project references to enable faster TypeScript builds.

See Project References handbook page for more documentation.

Tuples in rest parameters and spread expressions

TypeScript 3.0 adds support to multiple new capabilities to interact with function parameter lists as tuple types.TypeScript 3.0 adds support for:

• Expansion of spread expressions with tuple types into discrete arguments.
• Optional elements in tuple types.
• With these features it becomes possible to strongly type a number of higher-order functions that transform functions and their parameter lists.

Rest parameters with tuple types

When a rest parameter has a tuple type, the tuple type is expanded into a sequence of discrete parameters.For example the following two declarations are equivalent:

declare function foo(args_0: number, args_1: string, args_2: boolean): void;

When a function call includes a spread expression of a tuple type as the last argument, the spread expression corresponds to a sequence of discrete arguments of the tuple element types.

Thus, the following calls are equivalent:

const args: [number, string, boolean] = [42, "hello", true];
foo(42, "hello", true);
foo(args[0], args[1], args[2]);
foo(...args);

Generic rest parameters

A rest parameter is permitted to have a generic type that is constrained to an array type, and type inference can infer tuple types for such generic rest parameters. This enables higher-order capturing and spreading of partial parameter lists:

Example

In the declaration of f2 above, type inference infers types number, [string, boolean] and void for T, U and V respectively.

Optional elements in tuple types

Tuple types now permit a ? postfix on element types to indicate that the element is optional:

Example

let t: [number, string?, boolean?];
t = [42, "hello", true];
t = [42, "hello"];
t = [42];

In —strictNullChecks mode, a ? modifier automatically includes undefined in the element type, similar to optional parameters.

A tuple type permits an element to be omitted if it has a postfix ? modifier on its type and all elements to the right of it also have ? modifiers.

When tuple types are inferred for rest parameters, optional parameters in the source become optional tuple elements in the inferred type.

The length property of a tuple type with optional elements is a union of numeric literal types representing the possible lengths.For example, the type of the length property in the tuple type [number, string?, boolean?] is 1 | 2 | 3.

The last element of a tuple type can be a rest element of the form , where X is an array type.A rest element indicates that the tuple type is open-ended and may have zero or more additional elements of the array element type.For example, [number, …string[]] means tuples with a number element followed by any number of string elements.

Example

function tuple<T extends any[]>(...args: T): T {
    return args;
}
const numbers: number[] = getArrayOfNumbers();
const t2 = tuple("bar", ...numbers);  // [string, ...number[]]

The type of the length property of a tuple type with a rest element is number.

TypeScript 3.0 introduces a new top type unknown.unknown is the type-safe counterpart of any.Anything is assignable to unknown, but unknown isn’t assignable to anything but itself and any without a type assertion or a control flow based narrowing.Likewise, no operations are permitted on an unknown without first asserting or narrowing to a more specific type.

Example

Support for defaultProps in JSX

TypeScript 3.0 adds support for a new type alias in the JSX namespace called LibraryManagedAttributes.This helper type defines a transformation on the component’s Props type, before using to check a JSX expression targeting it; thus allowing customization like: how conflicts between provided props and inferred props are handled, how inferences are mapped, how optionality is handled, and how inferences from differing places should be combined.

In short using this general type, we can model React’s specific behavior for things like defaultProps and, to some extent, propTypes.

export interface Props {
    name: string;
export class Greet extends React.Component<Props> {
    render() {
        const { name } = this.props;
        return <div>Hello {name.toUpperCase()}!</div>;
    }
    static defaultProps = { name: "world"};
}
// Type-checks! No type assertions needed!
let el = <Greet />

Caveats

Explicit types on defaultProps

The default-ed properties are inferred from the defaultProps property type. If an explicit type annotation is added, e.g. static defaultProps: Partial<Props>; the compiler will not be able to identify which properties have defaults (since the type of defaultProps include all properties of Props).

Use static defaultProps: Pick<Props, "name">; as an explicit type annotation instead, or do not add a type annotation as done in the example above.

For function components (formerly known as SFCs) use ES2015 default initializers:

function Greet({ name = "world" }: Props) {
    return <div>Hello {name.toUpperCase()}!</div>;
}

Changes to @types/React

Corresponding changes to add LibraryManagedAttributes definition to the JSX namespace in @types/React are still needed.Keep in mind that there are some limitations.

TypeScript adds a new triple-slash-reference directive (/// <reference lib="name" />), allowing a file to explicitly include an existing built-in lib file.

Built-in lib files are referenced in the same fashion as the "lib" compiler option in tsconfig.json (e.g. use lib="es2015" and not lib="lib.es2015.d.ts", etc.).

Example

Using /// <reference lib="es2017.string" /> to one of the files in a compilation is equivalent to compiling with .