typescript

타입 스크립트 5.5 업데이트 모든 내용 요약

하리하링웹 2024. 7. 22. 14:03

Inferred Type Predicates

5.4

functionmakeBirdCalls(countries: string[]) {
  // birds: (Bird | undefined)[]
const birds = countries
    .map(country => nationalBirds.get(country))
    .filter(bird => bird !== undefined);

for (const birdof birds) {
    bird.sing();  // error: 'bird' is possibly 'undefined'.
  }
}

5.5

functionmakeBirdCalls(countries: string[]) {
  // birds: Bird[]
const birds = countries
    .map(country => nationalBirds.get(country))
    .filter(bird => bird !== undefined);

for (const birdof birds) {
    bird.sing();  // ok!
  }
}

배열의 타입 추론이 개선됨. 예를 들어 아래 5.5 코드 처럼 undefined를 filter 하는 경우 typescript가 알아서 타입을 추론해주도록 개선

아래가 아주 적절한 예시

// Previously, nums: (number | null)[]
// Now, nums: number[]
const nums = [1, 2, 3, null, 5].filter(x => x !== null);

nums.push(null);  // ok in TS 5.4, error in TS 5.5

만약 위처럼 자동으로 추론하는 것이 마음에 들지 않으면 아래처럼 명시적으로 nums에 타입 지정을 해서 동작하게 만들수도 있음

const nums: (number | null)[] = [1, 2, 3, null, 5].filter(x => x !== null);
nums.push(null);  // ok in all versions

아래와 같은 경우에 단순하게 체크만 하는 것이 아니라 주석의 코드처럼 명시적으로 대상을 number타입으로 추론해줌

// const isNumber: (x: unknown) => x is number
const isNumber = (x: unknown) => typeof x === 'number';

// const isNonNullish: <T>(x: T) => x is NonNullable<T>
const isNonNullish = <T,>(x: T) => x != null;

https://github.com/microsoft/TypeScript/pull/57465

Control Flow Narrowing for Constant Indexed Accesses

기존에는 아래 코드에서 에러가 발생했는데 이제는 인덱스와 객체가 상수라면 이를 연관지어 타입을 자동으로 추론해줌

function f1(obj: Record<string, unknown>, key: string) {
    if (typeof obj[key] === "string") {
        // Now okay, previously was error
        obj[key].toUpperCase();
    }
}

https://github.com/microsoft/TypeScript/pull/57847

The JSDoc @import Tag

자바 스크립트 런타임에서 아래 SomeType은 존재하지 않기에 에러가 발생하게 됨

// ./some-module.d.ts
export interface SomeType {
    // ...
}

// ./index.js
import { SomeType } from "./some-module"; // ❌ runtime error!

/**
 * @param {SomeType} myValue
 */
function doSomething(myValue) {
    // ...
}

기존에는 이 문제를 해결하기 위해 아래 방식으로 해결 함.

네임 스페이스 사용

import *as someModulefrom "./some-module";

/**
 *@param {someModule.SomeType} myValue
 */
functiondoSomething(myValue) {
    // ...
}

주석에서 import

/**
 *@param {import("./some-module").SomeType} myValue
 */
functiondoSomething(myValue) {
    // ...
}

typedef 사용

/**
 *@typedef {import("./some-module").SomeType} SomeType
 */

/**
 *@param {SomeType} myValue
 */
functiondoSomething(myValue) {
    // ...
}

5.5 타입스크립트 에서는 ECMA 문법처럼 주석 태그에 @import 구문을 지원함

/**@import { SomeType } from "some-module" */

/**
 *@param {SomeType} myValue
 */
functiondoSomething(myValue) {
    // ...
}

네임 스페이스에도 사용 가능

/**@import * as someModule from "some-module" */

/**
 *@param {someModule.SomeType} myValue
 */
functiondoSomething(myValue) {
    // ...
}

이는 주석이기에 런타임에서 잘못 동작할 가능성도 없으며 기존 문법과 통일성도 지켜지기에 더 보기좋은 코드를 만들 수 있음.

https://github.com/microsoft/TypeScript/pull/57207

Regular Expression Syntax Checking

이제 타입스크립트에서 정규 표현식의 문법 체크도 지원해줌

문법 검사

닫는 괄호의 위치가 잘못됨

let myRegex = /@robot(\\s+(please|immediately)))?do some task/;
//                                            ~
// error!
// Unexpected ')'. Did you mean to escape it with backslash?

잘못된 역참조 체크

존재하지 않는 3 번쨰 그룹을 참조하려 하고있음

let myRegex = /@typedef \\{import\\((.+)\\)\\.([a-zA-Z_]+)\\} \\3/u;
//                                                        ~
// error!
// This backreference refers to a group that does not exist.
// There are only 2 capturing groups in this regular expression.

namedImport 캡처 그룹이 존재하지 않는데 이를 참조하려 하고 있음

let myRegex = /@typedef \\{import\\((?<importPath>.+)\\)\\.(?<importedEntity>[a-zA-Z_]+)\\} \\k<namedImport>/;
//                                                                                        ~~~~~~~~~~~
// error!
// There is no capturing group named 'namedImport' in this regular expression.

버전 호환성 체크

자바스크립트 환경이 ES2018이전 버전이라 아래(캡처 그룹) 문법을 지원하지 않음

let myRegex = /@typedef \\{import\\((?<importPath>.+)\\)\\.(?<importedEntity>[a-zA-Z_]+)\\} \\k<importedEntity>/;
//                                  ~~~~~~~~~~~~         ~~~~~~~~~~~~~~~~
// error!
// Named capturing groups are only available when targeting 'ES2018' or later.

https://github.com/microsoft/TypeScript/pull/55600

Support for New ECMAScript Set Methods

Set에 새로운 메서드 추가

집합 연산을 수행하는 메서드: union, intersection, difference, symmetricDifference
논리 연산을 수행하는 메서드: isSubsetOf, isSupersetOf, isDisjointFrom

동작 예시)

let fruits = new Set(["apples", "bananas", "pears", "oranges"]);
let applesAndBananas = new Set(["apples", "bananas"]);
let applesAndOranges = new Set(["apples", "oranges"]);
let oranges = new Set(["oranges"]);
let emptySet = new Set();

////
// union
////

// Set(4) {'apples', 'bananas', 'pears', 'oranges'}
console.log(fruits.union(oranges));

// Set(3) {'apples', 'bananas', 'oranges'}
console.log(applesAndBananas.union(oranges));

////
// intersection
////

// Set(2) {'apples', 'bananas'}
console.log(fruits.intersection(applesAndBananas));

// Set(0) {}
console.log(applesAndBananas.intersection(oranges));

// Set(1) {'apples'}
console.log(applesAndBananas.intersection(applesAndOranges));

////
// difference
////

// Set(3) {'apples', 'bananas', 'pears'}
console.log(fruits.difference(oranges));

// Set(2) {'pears', 'oranges'}
console.log(fruits.difference(applesAndBananas));

// Set(1) {'bananas'}
console.log(applesAndBananas.difference(applesAndOranges));

////
// symmetricDifference
////

// Set(2) {'bananas', 'oranges'}
console.log(applesAndBananas.symmetricDifference(applesAndOranges)); // no apples

////
// isDisjointFrom
////

// true
console.log(applesAndBananas.isDisjointFrom(oranges));

// false
console.log(applesAndBananas.isDisjointFrom(applesAndOranges));

// true
console.log(fruits.isDisjointFrom(emptySet));

// true
console.log(emptySet.isDisjointFrom(emptySet));

////
// isSubsetOf
////

// true
console.log(applesAndBananas.isSubsetOf(fruits));

// false
console.log(fruits.isSubsetOf(applesAndBananas));

// false
console.log(applesAndBananas.isSubsetOf(oranges));

// true
console.log(fruits.isSubsetOf(fruits));

// true
console.log(emptySet.isSubsetOf(fruits));

////
// isSupersetOf
////

// true
console.log(fruits.isSupersetOf(applesAndBananas));

// false
console.log(applesAndBananas.isSupersetOf(fruits));

// false
console.log(applesAndBananas.isSupersetOf(oranges));

// true
console.log(fruits.isSupersetOf(fruits));

// false
console.log(emptySet.isSupersetOf(fruits));

https://github.com/microsoft/TypeScript/pull/57230

Isolated Declarations

타입 스크립트 코드 컴파일 시 기존 declaration보다 더 효율적으로 빠르게 선언 파일을 만들어 주는 isolatedDeclarations 기능 추가, 특히 대규모 프로젝트, 멀티 코어 CPU 사용 시 빌드 속도를 높이는 데 도움이 됨.

useCase

.d.ts 파일을 빠르게 생성하고 싶을 때
모노레포 구조에서 의존성 관계에 있는 모듈들을 병렬로 작업하고 싶을 때
- 아래 이미지의 경우 frontend, backend는 core에 의존하고 있기에 .d.ts 파일을 생성하려면 frontend, backend는 core의 타입 추론이 완료될 때 까지 아무런 작업을 하지 못한다. 하지만 isolated declaration을 사용하면 명시적으로 타입을 생성하기에 기다리지 않아도 .d.ts 를 생성할 수 있게 된다.

이런 useCase를 충족시키기 위해 나온 것이 isolatedDeclarations 옵션이다. 이는 아래 코드처럼 모듈을 내보내는 경우 충분한 정보가 없으면 에러를 반환한다.

export function foo() {
//              ~~~
// error! Function must have an explicit
// return type annotation with --isolatedDeclarations.
    return x;
}

이를 통해 타입스크립트가 선언 파일에 문제가 생길지에 대한 유무를 미리 알려주며 개발자가 이를 수정할 수 있도록 도와준다.

아래처럼 반환 타입이 명확한 경우에는 따로 타입을 알려주지 않아도 타입스크립트가 알아서 처리해준다.

// No error on 'x'.
// It's trivial to calculate the type is 'number'
export let x = 10;

// No error on 'y'.
// We can get the type from the return expression.
export function y() {
    return 20;
}

// No error on 'z'.
// The type assertion makes it clear what the type is.
export function z() {
    return Math.max(x, y()) as number;
}

isolatedDeclarations 옵션의 구현 사항을 만족한 코드가 바로 아래 코드이다.

// add.ts
export function add(a: string, b: string): string {
    return a + b;
}

// foo.ts
import { add } from "./add";

const x = add("1", "2");

export function foo(): string {
    return x;
}

isolatedDeclarations 옵션을 사용하고 있는 위 코드의 경우 tsc 컴파일에서 선언파일을 생설할 때 add 함수의 구현을 분석하지 않고도 파일을 생성할 수 있게된다.

아직 isolatedDeclarations 옵션은 초기 기능이기에 반환타입을 명시하지 않은 경우 에러를 발생시키지 않고 스스로 isolatedDeclarations 없이 컴파일을 해주는 등 개발 편의성을 높여주는 기능은 없으며 클래스, 객체 리터럴 선언시에는 지원되지 않는 등 불편한 점이 많다.

하지만 이 옵션은 타입스크립트 컴파일 병렬 처리의 가능성을 보여주는 기능이기에 업데이트 되는 것을 지켜볼 가치가 있다.

일단 현재는 개발 편의성을 해칠 가능성이 높으니 확실한 분석을 한 이후 사용하는 것을 추천한다.

isolated declaration 토론 링크

https://github.com/microsoft/TypeScript/pull/58201

The ${configDir} Template Variable for Configuration Files

tsconfig 내부에서 아래와 같이 tsconfig.base.json 파일을 extends 하여 template 느낌으로 사용하는 경우가 많음

{
    "extends": "../../tsconfig.base.json",
    "compilerOptions": {
        "outDir": "./dist"
    }
}

이 떄 아래처럼 상대 경로를 사용하면 경로가 공유 파일을 기준으로 하기에 번거롭게 각 tsconfig에서 직접 경로를 설정해야하는 문제가 발생하게됨

{
    "compilerOptions": {
        "typeRoots": [
            "./node_modules/@types"
            "./custom-types"
        ],
        "outDir": "dist"
    }
}

이제 이런 설정 없이도 아래와 같이 사용 시 경로가 자동으로 해당 tsconfig를 기반으로 설정되게됨

{
    "compilerOptions": {
        "typeRoots": [
            "${configDir}/node_modules/@types",
            "${configDir}/custom-types"
        ],
        "outDir": "${configDir}/dist"
    }
}

https://github.com/microsoft/TypeScript/pull/58042

Consulting package.json Dependencies for Declaration File Generation

기존 버전에서는 declaration 파일 생성 시 아래와 같은 경우 에러 발생 가능성이 존재했음

// 파일 A.ts
import { SomeType } from './B';

export const x: SomeType = { ... };

// 파일 B.ts
import { AnotherType } from './C';

export type SomeType = AnotherType & { ... };

// 파일 C.ts
export type AnotherType = { ... };

파일 A가 선언 파일을 생성할 때, 파일 C의 AnotherType을 참조해야 하는데, 파일 B와 파일 C가 명시적으로 import되지 않았을 경우 이를 가져올 수 없기에 문제가 발생했음

5.5에서는 이를 더 관대하게 처리해서 에러 발생 가능성을 낮추도록 개선함

ex) package.json 파일의 dependencies (또는 peerDependencies 및 optionalDependencies)에 명시된 명시적 종속성을 가진 코드베이스의 경우, 이러한 import를 생성하는 것이 안전

https://github.com/microsoft/TypeScript/issues/42873

Editor and Watch-Mode Reliability Improvements

TSServer, editor의 재시작 횟수 감소 및 안정성 향상을 위해 --watch 모드와 TypeScript editor에 대한 몇 가지 로직 개선

Correctly Refresh Editor Errors in Configuration Files

기존 tsconfig는 프로젝트 로드 시 에러를 발생시켜 이를 수정하더라도 즉시 반영되지 않았음. 5.5에서는 의도적으로 에러 이벤트를 발생시켜서 에러 수정 시 프로젝트 로드 없이 즉각 반영되도록 개선

https://github.com/microsoft/TypeScript/pull/58120

Better Handling for Deletes Followed by Immediate Writes

npm ci 처럼 파일을 덮어 쓰는 대신 삭제하고 새로 만드는 명령어의 경우 기존 typescript에서는 삭제된 파일에 대한 의존성 이슈때문에 전체 프로젝트를 리빌딩하는 이슈가 존재했음. 5.5에서는 이런 경우에 대해 개선함

https://github.com/microsoft/TypeScript/pull/57492

Symlinks are Tracked in Failed Resolutions

기존에는 모듈 단위에서 타입 체크 실패 시 파일 추가 혹은 해당 경로 타입이 수정될 수 있으므로 해당 경로를 감시하고 있었는데 이 때 심볼릭 링크된 디렉토리에는 이 작업이 일어나지 않아 모노레포와 같은 경우 데이터를 새로 시작해야 적용이 되는 문제가 있었음. 5.5에서는 심볼릭 링크에 대해서도 이를 감시하여 재시작 하지 않아도 잘 적용이 되도록 변경됨

https://github.com/microsoft/TypeScript/pull/58139

Project References Contribute to Auto-Imports

auto import 기능이 의존하는 프로젝트에 대해 한 개 이상의 명시적 import를 요구하지 않게 됨. 대신 tsconfig의 references를 참고하는 것만으로도 auto import 기능이 정상 동작하도록 변경

https://github.com/microsoft/TypeScript/pull/55955

Performance and Size Optimizations Monomorphized Objects in Language Service and Public API

5.0에서 Node와 Symbol객체가 일관된 속성 세트, 초기화 순서를 갖도록 변경하여 컴파일 속도 개선이 있었는데 typesciprt public api, language service에는 다른 객체 할당자를 사용해서 영향이 없었음 5.5에서는 위 두 개 항목에도 동일한 작업을 수행하도록 하여 language service의 작업 속도가 약 10~20% 빨라지고 public api의 빌드 속도가 약 5~8% 빨라짐 단 메모리 사용량이 조금 증가하게됨

https://github.com/microsoft/TypeScript/pull/58045

Monomorphized Control Flow Nodes

노드의 control flow graph를 단일화하여 typescript가 이를 분석할 때 약 1%의 체크 시간이 단축됨

https://github.com/microsoft/TypeScript/pull/57977

Optimizations on our Control Flow Graph

많은 케이스에서 control flow 분석은 새로운 정보가 주어지지 않는 노드를 탐색하는데 이런 노드들은 건너뛰어도 문제가 생기지 않음 5.5에서는 이 탐색 방식을 효율적으로 변경하여 최대 2%의 빌드 성능 향상을 가져오며 대규모 codebase에서 효과적일것이라고 예상됨

https://github.com/microsoft/TypeScript/pull/58013

Skipped Checking in transpileModule and transpileDeclaration

기존 transpileModule, transpileDeclaration 와 같이 typescript 파일을 javascript로 변환 혹은 새로운 선언 파일을 생성하는 역할을 하는 API는 하나의 결과물을 생성하기 위해 파일의 전체 내용을 완전하게 타입 체크해야 하는 문제가 있었음(이후 사용될 정보를 수집하기 위함) typescript 5.5에서는 이러한 전체 검사를 수행하지 않고 필요한 경우에만 검사를 수행하는 lazy collecting 기능을 도입했으며 transpileModule, transpileDeclaration 의 기본 옵션으로 적용 됨. 이로인해 이 API를 사용하는 도구를 사용하는 경우 (ex)ts-loader의 transpileOnly, ts-jest) 약 2배의 빌드 속도 향상이 있음

https://github.com/microsoft/TypeScript/pull/58364

TypeScript Package Size Reduction

typescript 5.0 모듈을 사용하여 typescript 패키지의 tsserver, typingInstaller를 공통된 라이브러리에서 가져오도록 변경함 이로인해 패키지 사이즈를 약 30% 감소시킴

https://github.com/microsoft/TypeScript/pull/55326

Node Reuse in Declaration Emit

isolatedDeclarations api 작업을 위해 선언 파일 생성 시 코드를 직접적으로 복사하는 빈도를 크게 개선시킴

아래의 코드를 예로 들어보자

export const strBool: string | boolean = "hello";
export const boolStr: boolean | string = "world";

유니온 타입이 동일하지만 유니온의 순서가 다른 경우, TypeScript는 선언 파일을 생성할 때 두 가지 가능한 출력 방식을 가질 수 있음.

첫 번째 방식은 각 타입에 대해 일관된 순서를 가지는 것

typescriptCopy code
export const strBool: string | boolean;
export const boolStr: string | boolean;

두 번째 방식은 작성된 그대로의 순서를 따르는 것

typescriptCopy code
export const strBool: string | boolean;
export const boolStr: boolean | string;

두 번째 접근 방식이 일반적으로 더 선호되는 방식이며 이유는 아래와 같음

선언 파일에 의도를 담을 수 있음
일관된 표현 방식을 지키는것에 비용이 듬
사용자 작성 타입은 일관된 표현 방식을 지키기 위해 생성된 타입보다 짧음

5.5에서는 입력 그대로 타입을 사용하는 것에 대한 위치를 크게 늘려 성능 개선 가능성을 더 높임

Caching Contextual Types from Discriminated Unions

typescript는 객체 리터럴 유니온 타입의 타입을 요청할 때 식별된 타입들을 기반으로 유니온 타입을 필터링 하려고 한다. 이 때 이 객체의 크기가 크면 클수록 비용이 더욱 커지는데 5.5에서는 이 객체를 캐시하여 다시 계산할 필요가 없도록 개선하였다.

이를 통해 typescript 컴파일러 자체를 compile 할 때 걸리는 시간이 250ms 감소되었으며 대규모 코드 베이스에서 효과적인 성능 개선을 얻을 수 있게됨

https://github.com/microsoft/TypeScript/pull/58372

Easier API Consumption from ECMAScript Modules

node에서 ECMAScript Module 작성 시 Named import가 되지 않던걸 되게 만듬

import { createSourceFile } from "typescript"; // ❌ error

import * as ts from "typescript";
ts.createSourceFile // ❌ undefined???

ts.default.createSourceFile // ✅ works - but ugh!

5.5

import { createSourceFile } from "typescript"; // ✅ works now!

import * as ts from "typescript";
ts.createSourceFile // ✅ works now!

https://github.com/microsoft/TypeScript/pull/57133

The transpileDeclaration API

기존 transpileModule API는 단일 typescript파일을 compile하기 위해 사용하는 api였음 typescript 5.5에서는 transpileDeclaration 이라는 새 api를 추가하여 단일 typescript 파일에 대한 선언 파일을 생성할 수 있게 만들어줌 다만 이번에 새로 생긴 isolatedDeclarations api 에서 에러가 없을 경우에만 정상 동작하며 이를 통해 전체 코드 로드 없이 빠르게 효율적으로 단일 파일에 대한 선언 파일 생성이 가능해짐

https://github.com/microsoft/TypeScript/pull/58261

Notable Behavioral Changes

TypeScript 5.0에서 deprecated 기능

TypeScript 5.0에서는 아래 옵션들이 deprecated 됨

charset
target: ES3
importsNotUsedAsValues
noImplicitUseStrict
noStrictGenericChecks
keyofStringsOnly
suppressExcessPropertyErrors
suppressImplicitAnyIndexErrors
out
preserveValueImports
prepend in project references
implicitly OS-specific newLine

ignoreDeprecations 옵션을 5.0으로 지정하여 위 기능을 사용할 수 있었으나

typescript 5.5에서는 위 기능들이 아예 동작하지 않게 됨 업그레이드를 위해 명시는 할 수 있으나 6.0에서는 에러가 발생하게 되니 typescript 기반 프로젝트를 사용중이면 빨리 개선하는것이 좋아보임

Flag Deprecation Plan

lib.d.ts Changes

DOM 타입 정의에 대한 변경 사항이 있으며 이는 코드베이스에 영향을 미칠 수 있음

https://github.com/microsoft/TypeScript/pull/58211

Stricter Parsing for Decorators

decorator의 문법 체크가 더욱 엄격해짐, 기존 decorator중 아래와 같은 경우에는 괄호로 묶어야 에러가 발생 안하게 변경

class DecoratorProvider {
    decorate(...args: any[]) { }
}

class D extends DecoratorProvider {
    m() {
        class C {
            @super.decorate // ❌ error
            method1() { }

            @(super.decorate) // ✅ okay
            method2() { }
        }
    }
}

undefined is No Longer a Definable Type Name

기존 타입 스크립트에서는 아래처럼 타입을 타입 이름으로 사용할 수 없었음

// Illegal
type null = any;
// Illegal
type number = any;
// Illegal
type object = any;
// Illegal
type any = any;

버그로 인해 undefined는 타입 이름으로 사용할 수 있었는데 더 이상 undefined를 타입 이름으로 정의하여 사용할 수 없음

// Now also illegal
type undefined = any;

물론 undefined라는 타입 이름은 버그로 허용 되었을 뿐 애초에 정상적으로 동작하지는 않았음

export type undefined = string;
export const m: undefined = "";
//           ^
// Errors in 5.4 and earlier - the local definition of 'undefined' was not even consulted.

https://github.com/microsoft/TypeScript/pull/57575

Simplified Reference Directive Declaration Emit

기존 typescript는 원본 소스코드에 내용이 없더라도 선언 파일 생성 시 참조 파일이 필요하면 아래와 같이 reference 태그를 사용하여 참조 지시어를 명시하여 선언 파일을 생성하였음

[코드]

import path from "path";
export const myPath = path.parse(__filename);

[선언 파일]

/// <reference types="node" />
import path from "path";
export declare const myPath: path.ParsedPath;

반대의 경우 참조 파일이 필요 없다고 판단되는 경우 원본 소스코드에 지시어가 있더라도 제거하였음

isolatedDeclarations API 작업 도중 이러한 개념이 이해하기 어렵고 일관성이 없어 예측하기 어렵다고 판단하였음. 따라서 isolatedDeclarations API를 사용중인 경우엔 원본 소스와 선언 파일의 참조 지시어 내용이 달라지지 않도록 해야한다고 판단했음.

실험 결과 typescript가 생성한 참조 지시어의 대부분은 node, react 였으며 이는 다운스트림 사용자가 tsconfig를 통해 이미 types 혹은 import를 통해 해당 타입을 참조하고 있을 것으로 기대했으며 이를 통해 해당 참조 지시어를 생성하지 않아도 문제가 발생하지 않을 확률이 높았으며 작성자가 생성한 참조 지시어들은 선언 파일 생성시 대부분 제거되었으며 보존되더라도 대부분 의미가 없거나 의도하지 않았던 것으로 나타났음

이를 바탕으로 5.5에서는 참조 지시어를 크게 간소화 하기로 결정했음

5.5의 새로운 전략

참조 지시어는 더 이상 생성되지 않음
사용자가 작성하는 참조 지시어는 새로운 preserve="true" 속성이 있지 않은 이상 보존되지 않음

이제 아래의 소스 코드는

/// <reference types="some-lib" preserve="true" />
/// <reference types="jest" />
import path from "path";
export const myPath = path.parse(__filename);

아래의 선언 파일을 만들게됨

/// <reference types="some-lib" preserve="true" />
import path from "path";
export declare const myPath: path.ParsedPath;

preserve="true” 속성은 이전 버전과도 호환되는데 이유는 typescript는 알 수 없는 속성을 무시하기 떄문

이로 인해 선언 파일 생성 시 emit 단계의 성능이 1~4% 개선됨

What’s Next?

다음 버전은 typescript 5.6이며 9월 초에 출시 예정

typescript 5.6 버전은 현재 아래 명령어로 사용해볼 수 있음

npm install _D typescript@next

혹은 vscode의 typescript nightly extension으로 사용해볼수도 있음

참고 링크

https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/

저작자표시

'typescript' 카테고리의 다른 글

TypeScript 컴파일러에서의 진단 로직 (2)	2024.07.24
타입스크립트에서 타입 호환성은 어떻게 체크되는가? (1)	2024.03.13
타입스크립트의 제네릭이란 (1)	2024.03.07

현재글타입 스크립트 5.5 업데이트 모든 내용 요약

kjsik11@gmail.com / 잘못된 정보에 대한 피드백은 언제나 환영입니다.

re-rendering, PMTiles, test, builder, DevOps, useSWR, redux, TypeScript, docker, WEB, ECS, frontend, maplibre, mongodb, nextjs, EC2, JavaScript, AWS, React, node,

Today :
Yesterday :

하리하링웹

타입 스크립트 5.5 업데이트 모든 내용 요약

Inferred Type Predicates

5.4

5.5

Control Flow Narrowing for Constant Indexed Accesses

The JSDoc @import Tag

Regular Expression Syntax Checking

Support for New ECMAScript Set Methods

Isolated Declarations

The ${configDir} Template Variable for Configuration Files

Consulting package.json Dependencies for Declaration File Generation

Editor and Watch-Mode Reliability Improvements

Correctly Refresh Editor Errors in Configuration Files

Better Handling for Deletes Followed by Immediate Writes

Symlinks are Tracked in Failed Resolutions

Project References Contribute to Auto-Imports

Performance and Size Optimizations Monomorphized Objects in Language Service and Public API

Monomorphized Control Flow Nodes

Optimizations on our Control Flow Graph

Skipped Checking in transpileModule and transpileDeclaration

TypeScript Package Size Reduction

Node Reuse in Declaration Emit

Caching Contextual Types from Discriminated Unions

Easier API Consumption from ECMAScript Modules

The transpileDeclaration API

Notable Behavioral Changes

TypeScript 5.0에서 deprecated 기능

lib.d.ts Changes

Stricter Parsing for Decorators

undefined is No Longer a Definable Type Name

Simplified Reference Directive Declaration Emit

5.5의 새로운 전략

What’s Next?

참고 링크

'typescript' 카테고리의 다른 글

'typescript'의 다른글

티스토리툴바

« 2025/04 »
일	월	화	수	목	금	토
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30

타입 스크립트 5.5 업데이트 모든 내용 요약

Inferred Type Predicates

5.4

5.5

Control Flow Narrowing for Constant Indexed Accesses

The JSDoc @import Tag

Regular Expression Syntax Checking

Support for New ECMAScript Set Methods

Isolated Declarations

The ${configDir} Template Variable for Configuration Files

Consulting package.json Dependencies for Declaration File Generation

Editor and Watch-Mode Reliability Improvements

Correctly Refresh Editor Errors in Configuration Files

Better Handling for Deletes Followed by Immediate Writes

Symlinks are Tracked in Failed Resolutions

Project References Contribute to Auto-Imports

Performance and Size Optimizations Monomorphized Objects in Language Service and Public API

Monomorphized Control Flow Nodes

Optimizations on our Control Flow Graph

Skipped Checking in transpileModule and transpileDeclaration

TypeScript Package Size Reduction

Node Reuse in Declaration Emit

Caching Contextual Types from Discriminated Unions

Easier API Consumption from ECMAScript Modules

The transpileDeclaration API

Notable Behavioral Changes

TypeScript 5.0에서 deprecated 기능

lib.d.ts Changes

Stricter Parsing for Decorators

undefined is No Longer a Definable Type Name

Simplified Reference Directive Declaration Emit

5.5의 새로운 전략

What’s Next?

참고 링크

'typescript' 카테고리의 다른 글

'typescript'의 다른글

관련글

티스토리툴바