가 나와 있었으므로, 읽어 보고 개인적으로 신경이 쓰인 것을 메모할까 생각합니다.

Control Flow Analysis of Aliased Conditions

function f(x: string | number | boolean) {
    const isString = typeof x === "string";
    const isNumber = typeof x === "number";
    const isStringOrNumber = isString || isNumber;
    if (isStringOrNumber) {
        x;  // Type of 'x' is 'string | number'.
    }
    else {
        x;  // Type of 'x' is 'boolean'.
    }
}

if문 밖에서 형 체크해도 그것이 계승되게 된다. 위대한, 실제로 이것을 만났다는 것을 느낀다.

Note that there’s a cutoff – TypeScript doesn’t go arbitrarily deep when checking these conditions, but its analysis is deep enough for most checks.

과연.

Symbol and Template String Pattern Index Signatures

interface Colors {
    [sym: symbol]: number;
}

이것을 사용하는 경우는 없었다고 생각한다. 주로 unique symbol를 사용하기 때문에. 하지만 지금까지 표현할 수 없었던 것이 가능하게 된 것은 좋다.

interface OptionsWithDataProps extends Options {
    // Permit any property starting with 'data-'.
    [optName: `data-${string}`]: unknown;
}

이것은 좋다. string에 할 수밖에 없었던 곳이 엄격하게 할 수 있다.

Defaulting to the unknown Type in Catch Variables ( --useUnknownInCatchVariables )

TypeScript 4.0 allowed users to specify an explicit type annotation of unknown
이미 할 수 있었던 것인가. opt-in이지만.

This flag is enabled under the --strict family of options

아, 좋다. 기존 코드에서 일부 오류가 발생할 것 같습니다. 당신이 생각하는 곳에는 몇 가지가 있습니다.

Exact Optional Property Types ( --exactOptionalPropertyTypes )

interface Person {
    name: string,
    age?: number;
}

// With 'exactOptionalPropertyTypes' on:
const p: Person = {
    name: "Daniel",
    age: undefined, // Error! undefined isn't a number
};

왜 그런 형태가 되어 있는지 이상하게 생각했던 것이다. 고칠까. 훌륭합니다.

This flag is not part of the --strict family

오, 미안해.

tsc --help Updates and Improvements

Performance Improvements

Spelling Suggestions for JavaScript

최근에는 JS별로 사용하지 않기 때문에 상관없다.

인레이 힌트

VSCode 사용하지 않기 때문에 혜택을 얻을 수 없다.

정리하면

4.4로 하면, catch는 unknown가 된다. 지금부터 : unknown 붙여 두면 조기 발견할 수 있을까. exactOptionalPropertyTypes는 스스로 유효하게 하지 않으면 안된다.