Improved Inference for Literal Types in TypeScript

Overview

TypeScript has had string literal types for a while. With TypeScript 2.0, the type system was extended by several new literal types:

Boolean literal types
Numeric literal types
Enum literal types

TypeScript 2.1 improves the type inference for all of these types when a const variable or readonly property has a literal initializer.

Better Inference for `const` Variables

Let’s start with local variables and the var keyword. When TypeScript sees the following variable declaration, it infers the type string for the baseUrl variable:

1
2


var baseUrl = "https://example.com/";
// Inferred type: string

The same goes for_{{ 适用于 }} variables declared with the let keyword:

1
2


let baseUrl = "https://example.com/";
// Inferred type: string

Both variables are inferred to have type string because they can change at any time. They are initialized with a literal string value, but they can be modified later.

However, if a variable is declared using the const keyword and initialized with a string literal, the inferred type is no longer string, but the corresponding string literal type:

1
2


const baseUrl = "https://example.com/";
// Inferred type: "https://example.com/"

The inferred type should be as specific as possible since the value of a constant string variable can never change. It’s impossible for the baseUrl variable to hold any other value than "https://example.com/". This information is now reflected in the type system.

Literal type inference works for other primitive types, too. If a constant is initialized with an immediate_{{ An immediate result, action, or reaction happens or is done without any delay }} numeric or boolean value, a literal type is inferred as well:

1
2
3
4
5


const HTTPS_PORT = 443;
// Inferred type: 443

const rememberMe = true;
// Inferred type: true

Similarly, a literal type is inferred when the initializer is an enum value:

1
2
3
4
5
6
7


enum FlexDirection {
  Row,
  Column,
}

const direction = FlexDirection.Column;
// Inferred type: FlexDirection.Column

Note that direction is typed as FlexDirection.Column, which is an enum literal type. Had we used the let or var keyword to declare the direction variable, its inferred type would’ve been FlexDirection instead.

Better Inference for `readonly` Properties

Similar to local const variables, readonly properties with a literal initializer are inferred to be of a literal type as well:

1
2
3
4
5
6
7
8


class ApiClient {
  private readonly baseUrl = "https://api.example.com/";
  // Inferred type: "https://api.example.com/"

  request(endpoint: string) {
    // ...
  }
}

Read-only class properties can only be initialized right away or from within a constructor. Attempting to change the value in other places results in a compile-time error. Therefore, it is reasonable_{{ 合理的 }} to infer a literal type for a read-only class property because its value doesn’t change (given that the TypeScript program is type-correct).

Of course, TypeScript can’t know what happens at run-time: properties marked with readonly can be changed at any time by some piece of JavaScript code. The readonly modifier is meant to restrict access to a property from within TypeScript code, but it has no run-time manifestation_{{ 表现，显现 }} at all. That is, it is compiled away and doesn’t show up in the generated JavaScript code.

Usefulness of Inferred Literal Types

You might ask yourself why it is useful to infer literal types for const variables and readonly properties. Consider the following code example:

1
2
3
4
5
6
7
8


const HTTP_GET = "GET"; // Inferred type: "GET"
const HTTP_POST = "POST"; // Inferred type: "POST"

function request(url: string, method: "GET" | "POST") {
  // ...
}

request("https://example.com/", HTTP_GET);

If the HTTP_GET constant was inferred to have type string instead of "GET", you’d get a compile-time error because you wouldn’t be able to pass HTTP_GET as the second argument to the request function:

1

Argument of type 'string' is not assignable to parameter of type '"GET" | "POST"'.

Of course, it’s not allowed to pass any arbitrary string as a function argument if the corresponding parameter only allows two specific string values. When the literal types "GET" and "POST" are inferred for the two constants, though, it all works out_{{ If a situation works out well or works out, it happens or progresses in a satisfactory way }}.

Next up: widening and non-widening literal types and the difference between the two.