What’s new in TypeScript 4.2?

Typescript’s 4.2 was just released recently. What awesome features does this release bring? What impact does it have in your daily life as a Developer? Should you immediately update?

Here, we will be going through all the most exciting new features. Here is a summary:

• Smarter type alias preservation
• Leading/middle rest elements in tuple types
• Stricter checks for the in operator
• –noPropertyAccessFromIndexSignature
• Template literal expressions have template literal types
• Improved uncalled function checks in logical expressions
• Better understanding of the compile process
• Support for Abstract Constructor Types

To get an editor with the latest Typescript version use Visual Studio Code Insiders. You can use a plugin alternatively for VS Code.

If you just want to have a play while reading the article you can use the Typescript Playground here. It is a fun and super easy tool to use.

Smarter Type Alias Preservation

Sometimes TypeScript just doesn’t resolve types properly. It may return the correct types but just not return the correct alias. The alias could be important and shouldn’t be lost along the way.

Let’s check this function:

export type BasicPrimitive = number | bigint;

export function divisablePer0(value: BasicPrimitive) {
    if (value === 0) {
        return undefined;
    }

    return value;
}

type ReturnAlias = ReturnType<typeof divisablePer0>; // number | bigint | undefined

Notice that an undefined type needs to be added to the method return type as it’s returning undefined on some scenarios.

Before 4.2 the return of type divisablePer0 is number | bigint | undefined. That type is indeed correct but we have lost some information. The alias BasicPrimitive got lost in the process, which is a handy piece of information to have.

If we do the same on TypeScript 4.2 we get the correct alias:

export type BasicPrimitive = number | bigint;

export function divisablePer0(value: BasicPrimitive) {
    if (value === 0) {
        return undefined;
    }

    return value;
}

type ReturnAlias = ReturnType<typeof divisablePer0>; // BasicPrimitive | undefined

Now the method divisablePer0 has the proper return type: BasicPrimitive | undefined. That makes your code more readable just by upgrading.

Leading/middle Rest Elements in Tuple Types

In the article about mapped types here we already looked at TypeScript Tuples. As a refresher, let’s revisit the example:

let arrayOptions: [string, boolean, boolean];
arrayOptions = ['config', true, true]; // works
arrayOptions = [true, 'config', true];
//             ^^^^^  ^^^^^^^^^
// Does not work: incompatible types

function printConfig(data: string) {
  console.log(data);
}

printConfig(arrayOptions[0]);

However, we forgot to check whether Tuples can use optional elements. Let’s see what the previous example would look like:

let arrayOptions: [string, boolean?, boolean?];
arrayOptions = ['config', true, true]; // works
arrayOptions = ['config', true]; // works too
arrayOptions = ['config']; // works too

function printConfig(data: string) {
  console.log(data);
}

printConfig(arrayOptions[0]);

Prior to 4.2 we could even use the spread operator to indicate a dynamic number of elements:

let arrayOptions: [string, ...boolean[]];

arrayOptions = ['config', true, true]; // works
arrayOptions = ['config', true]; // works too
arrayOptions = ['config']; // works too

function printConfig(data: string) {
  console.log(data);
}

printConfig(arrayOptions[0]);

In this new TypeScript, version Tuples become more powerful. Previously, we could use the spread operator but we couldn’t define the last element types.

let arrayOptions: [string, ...boolean[], number];
arrayOptions = ['config', true, true, 12]; // works
arrayOptions = ['config', true, 12]; // works too
arrayOptions = ['config', 12]; // works too

function printConfig(data: string) {
  console.log(data);
}

printConfig(arrayOptions[0]);

Note that something like this is invalid:

let arrayOptions: [string, ...boolean[], number?];

An optional element can’t follow a rest element. However, note that …boolean[] does accept an empty array, so that Tuple would accept [string, number] types.

Let’s see that in detail in the following example:

let arrayOptions: [string, ...boolean[], number];
arrayOptions = ['config', 12]; // works

Stricter Checks for the in Operator

The in operator is handy to know if a method or a property is in an object. However, in JavaScript, it will fail at runtime if it’s checked against a primitive.

Now, when you try to do this:

"method" in 23
//          ^^
// Error: The right-hand side of an 'in' expression must not be a primitive.

You’ll get an error telling you explicitly what’s going on. As this operator has been made stricter this release might introduce breaking changes.

--noPropertyAccessFromIndexSignature

Yet another compiler configuration that’s always interesting. In TypeScript, you can access properties using the bracketed element syntax or the dot syntax like JavaScript. That accessor is possible when the key is a string.

interface Person {

name: string;

}

const p: Person = { name: 'Max };

console.log(p.name) // Max

console.log(p['name']) // Max

There’s a situation that has led to explicit property miss typing:

interface Person {

name: string;

[key: string]: string;

}

const p: Person = { name: 'Max };

console.log(p.namme) // undefined

console.log(p['namme']) // undefined

Note how we are accessing the wrong property namme but because it fits the [key: string] implicit one, TypeScript won’t fail.

Enabling –noPropertyAccessFromIndexSignature will make TypeScript look for the explicit property when using the dotted syntax.

interface Person {
  name: string;
  [key: string]: string;
}
const p: Person = { name: 'Max' };
console.log(p.namme)
//          ^^^^^^^^
// Error
console.log(p['namme']) // works fine

It’s not part of the strict configuration as this might not suit all developers and codebases.

Template Literal Expressions Have Template Literal Types

Template literal types were introduced in 4.1 and here they got smarter. Previously, you couldn’t define a type template usage template literals.

type PropertyType = `get${string}`;

function getProperty(property: PropertyType, target: any) {
    return target[property];
}

getProperty('getName', {}); // works

const propertyName = 'Name';

const x = `get${propertyName}`;

getProperty(x, {});
//         ^^^
// Error: Argument of type 'string' is not assignable to parameter of type '`get${string}`'

The core problem is that string expressions are resolving to type string which leads to this type of incompatibility:

const x = `get${propertyName}`; // string

However, with 4.2, template string expressions will always start out with the template literal type:

const x = `get${propertyName}`; // getName

Improved Uncalled Function Checks in Logical Expressions

TypeScript’s uncalled function checks apply within && and || expressions. Under –strictNullChecks you will check the following error now:

function isInvited(name: string) {
    return name !== 'Robert';
}

function greet(name: string) {
    if (isInvited) {
    //  ^^^^^^^^^
    // Error:
    // This condition will always return true since the function is always defined.
    // Did you mean to call it instead?
        return `Welcome ${name}`;
    }
    return `Sorry you are not invited`;
}

Better Understanding of the Compile Process

Sometimes it can be quite challenging to work out where the Typescript file definitions are pulled from. It’s sometimes a trial and error process.

It’s now possible to get a deeper insight into what’s going on, making the compiler more verbose, using the following:

tsc --explainFiles

Let’s see the result:

It is an awesome feature that will help you understand further Typescript’s internals.

For more information and to develop web application using TypeScript, Hire TypeScript Developer from us as we give you a high-quality product by utilizing all the latest tools and advanced technology. E-mail us any clock at – hello@hkinfosoft.com or Skype us: “hkinfosoft”. To develop custom web apps using TypeScript, please visit our technology page.

Content Source:

1. blog.logrocket.com