TypeScript 6.0 RC: 기능, 주요 변경 사항 및 준비 방법

홈 » Python » TypeScript 6.0 RC: 기능, 주요 변경 사항 및 준비 방법

TypeScript 6.0이 공식적으로 릴리스 후보(RC) 단계에 진입했습니다.그리고 이번 업데이트는 단순한 점진적 업데이트가 아닙니다. 이 버전은 컴파일러와 언어 서비스의 오랜 JavaScript 구현을 사용하는 마지막 주요 버전이며, 프로젝트가 TypeScript 7.0에서 완전히 새로운 Go 기반 엔진으로 전환하기 직전의 버전입니다. 이러한 이유만으로도 6.0은 매우 중요한 릴리스입니다. 내부적인 모든 것이 바뀌기 전에 건너야 할 다리와 같은 역할을 합니다.

npm에서 설치하여 오늘 바로 RC 버전을 사용해 볼 수 있습니다. 와:

npm install -D typescript@rc

TypeScript 6.0의 핵심 아이디어는 준비와 정렬입니다.이번 버전은 5.9에서 7.0으로의 전환을 매끄럽게 다듬고, 기본 설정을 강화하고, 과거의 불필요한 기능들을 제거하며, 향후 동작을 반영하거나 Temporal, ES2025 API, Map의 "upsert" 메서드와 같은 향후 JavaScript 기능을 노출하는 몇 가지 핵심 기능을 추가했습니다. 이 과정에서 미묘한 타입 시스템 조정, 새로운 컴파일러 플래그, 그리고 실제 프로젝트에 영향을 미칠 구성 기본값들이 추가되었습니다. 특히 이러한 변경 사항들이 중요한 역할을 할 것입니다. types, rootDir그리고 엄격함.

TypeScript 6.0은 Go 기반 7.0으로 가는 다리 역할을 합니다.

TypeScript 6.0은 기존 JavaScript 코드베이스의 마지막 주요 릴리스로 명시적으로 설계되었습니다.타입스크립트 팀은 컴파일러와 언어 서비스를 새롭게 재작성하고 있습니다. Go의 네이티브 모터네이티브 성능과 공유 메모리 병렬 처리를 활용하는 이 새로운 엔진은 TypeScript 7.0 이상에서 처음 선보일 예정이며, 6.0은 그 직전의 과도기적 단계입니다.

6.0 버전의 대부분의 호환성 파괴 변경 사항과 사용 중단 예정 기능은 향후 7.0 버전으로 업그레이드할 때 호환성을 유지하기 위한 것입니다.네이티브 아키텍처, 기존 모듈 시스템 및 오랜 특이 사항에서 효율적으로 지원할 수 없는 옵션은 제거되거나 명확하게 사용 중단됨으로 표시되며 예외 처리가 적용됩니다. "ignoreDeprecations": "6.0" 귀하의 tsconfig.json 6.0 버전에서는 사용 중단 경고 메시지를 표시하지 않도록 설정할 수 있습니다. 하지만 7.0 버전에서는 해당 옵션이 완전히 사라질 예정이므로 이 플래그는 더 이상 도움이 되지 않습니다.

설정 정리를 하기 전에 "7.0 버전이 나올 때까지 기다리자"라는 생각이 든다면, 그건 함정입니다.6.0 RC 버전은 여러분의 문제를 해결해야 하는 버전입니다. tsconfig타입을 표준화하고, 더 이상 사용되지 않는 플래그를 처리해야 합니다. 두 번의 큰 도약(5.x → 7.0)은 5.x → 6.0 → 7.0으로 작고 통제된 변경을 통해 진행하는 것보다 항상 더 큰 영향을 미칩니다.

6.0 베타 버전 이후 무엇이 바뀌었나요?

베타 버전과 RC 버전 사이에서 TypeScript 팀은 주로 향후 출시될 7.0 엔진과의 동작 일치에 집중했습니다.또한 타입 검사 및 DOM 타입 지정에 대한 몇 가지 구체적인 수정 사항이 있습니다.

한 가지 중요한 변경 사항은 제네릭 호출에 전달되는 함수 표현식의 유형 검사에 영향을 미칩니다.특히 JSX 환경에서 그렇습니다. 제네릭 함수가 콜백과 함께 호출될 때(예: React 또는 다른 JSX 컴포넌트에서), RC 버전은 7.0 버전의 동작을 더 정확하게 반영하도록 타입 추론을 강화합니다. 실제로, 이전에는 암묵적인 타입 추론에 의존했던 일부 호출은 이제 타입 검사를 제대로 수행하기 위해 명시적인 타입 인수가 필요하게 되지만, 기존 코드에서 더 많은 실제 버그를 발견할 수 있게 됩니다.

임포트 어설션 구문 사용 중단 기간이 연장되었습니다.TypeScript는 이미 이전 버전에 대해 경고를 표시하고 있었습니다. import ... assert {...} ECMAScript 제안이 속성 가져오기로 전환됨에 따라 정적 가져오기의 구문이 변경됩니다. with이제, 해당 사용 중단 권고 사항은 동적 가져오기를 사용하는 경우에도 적용됩니다. import() 어설션 객체와 함께 import(..., { assert: {...}})방향은 분명합니다. 모든 곳에서 속성을 가져오도록 전환하십시오.

DOM 라이브러리 유형이 최신 웹 플랫폼 표준에 맞춰 업데이트되었습니다.웹 환경에서 시간 관련 API에 대한 업데이트를 포함하여 여러 가지 개선 사항이 있습니다. 브라우저 앱을 개발하는 경우, 이러한 새로운 API를 기반으로 더욱 정확한 타입 정의와 향상된 에디터 도구를 활용할 수 있습니다.

전혀 사용하지 않는 함수는 문맥에 덜 민감합니다. this

TypeScript 6.0은 명시적인 함수 호출 없이 함수를 처리하는 방식에 미묘하지만 매우 실용적인 변화를 도입했습니다. this 타입 추론 중 사용역사적으로 명시적인 데이터 유형이 없는 매개변수를 가진 함수는 "문맥에 따라 달라지는" 함수로 간주될 수 있었습니다. 즉, 해당 매개변수와 this 타입은 사용되는 위치에 따라 달라집니다. 이는 제네릭 추론에 영향을 미치고 함수 구문에 따라 예상치 못한 동작을 초래할 수 있습니다.

생산자와 소비자 쌍을 사용하는 일반적인 헬퍼를 생각해 보세요.:

declare function callIt<T>(obj: {
  produce: (x: number) => T,
  consume: (y: T) => void,
}): void;

// Arrow functions: everything infers fine
callIt({
  produce: (x: number) => x * 2,
  consume: y => y.toFixed(),
});

// Flipped property order still fine with arrows
callIt({
  consume: y => y.toFixed(),
  produce: (x: number) => x * 2,
});

하지만 메서드 구문을 사용하면 이전 동작이 예상과 다를 수 있습니다.동일한 로직을 메서드로 작성하면 속성 순서가 변경될 때 오류가 발생할 수 있습니다. TypeScript가 제네릭 인수를 추론할 때 "문맥에 민감한" 함수를 건너뛰기 때문입니다. 메서드는 암묵적으로 다음과 같은 속성을 가집니다. this 매개변수로 인해 그들이 민감한 범주에 속하게 되었는데, 설령 그렇다 하더라도 this 실제로 언급된 적은 없습니다.

6.0 버전에서는 절대 읽지 않는 함수들이 있습니다. this 이제는 문맥에 덜 민감한 것으로 취급됩니다.달리 말하면, 컴파일러가 다음과 같은 것을 발견하면 this 함수 내부에서 전혀 사용되지 않으면 추론 과정에서 해당 함수에 불이익이 주어지지 않습니다. 즉, 메서드 구문과 화살표 함수 구문이 제네릭 추론 시나리오에서 훨씬 더 일관성을 갖게 되었으며, "특정 속성 순서에 따라 작동하고 다른 순서로 작동하지 않는" 이상한 동작이 사라집니다.

이번 변경 사항은 타입 추론 후보의 우선순위 지정을 개선합니다.: 사용되지 않는 함수 this 타입 인수를 추론할 때 더 높은 우선순위의 정보 소스가 됩니다. T그 효과는 덜 불가사의합니다. unknown 타입과 리팩토링 전반에 걸쳐 더욱 안정적인 추론 기능을 제공합니다. 이 작업은 Mateusz Burzyński가 기여했습니다.

Node 지원 #/ 하위 경로 가져오기

Node의 "하위 경로 가져오기" 기능은 패키지가 내부 가져오기 별칭을 정의할 수 있도록 합니다. imports 필드 package.json이러한 별칭은 깊은 상대 경로를 피함으로써 가져오기를 간소화합니다. 이전에는 모든 하위 경로 키에 초기 세그먼트 이후에 최소 하나 이상의 세그먼트가 있어야 했습니다. #이는 번들러 관례에 익숙한 사람들에게는 작지만 성가신 제약 사항이었습니다. @/....

TypeScript 6.0에서는 이제 로 시작하는 하위 경로 가져오기를 지원합니다. #/이는 최신 Node 20 동작 방식과 일치합니다. 즉, 다음과 같은 구성을 사용할 수 있습니다.

{
  "name": "my-package",
  "type": "module",
  "imports": {
    "#": "./dist/index.js",
    "#/*": "./dist/*"
  }
}

이러한 설정을 통해 패키지 내부의 모듈은 물론 소비자까지도 간결한 방식으로 가져올 수 있습니다. #/... 접두사 긴 상대 경로 대신에 ../../utils.jsTypeScript는 다음과 같은 경우 이 패턴을 이해합니다. --moduleResolution 가 node20, nodenext및 bundler이는 최신 Node.js의 의미론을 반영한 것입니다. 이 개선 사항은 magic-akari 님이 구현했습니다.

사용 --moduleResolution bundler 과 --module commonjs

이전 --moduleResolution bundler 다음과 함께 사용할 수 있습니다. --module esnext or preserve기존 방식의 사용 중단과 함께 node/node10 모듈 해결 모드에서는 많은 프로젝트가 현재 CommonJS 출력에 맞는 마이그레이션 경로가 필요했습니다.

TypeScript 6.0에서는 이제 결합이 가능합니다. --moduleResolution bundler 과 --module commonjs이러한 조합은 CommonJS를 사용하는 코드베이스이지만 번들러 중심 워크플로 또는 새로운 해결 로직으로 전환하려는 경우 실용적인 디딤돌이 되는 경우가 많습니다. 이후 프로젝트는 다음 두 가지 중 하나로 장기적인 마이그레이션을 계획할 수 있습니다.

• module: "preserve" 과 moduleResolution: "bundler" 웹 앱 번들 및 유사한 구성의 경우, 또는
• module: "nodenext" 최신 Node.js를 직접 대상으로 하는 환경에 적합합니다.

이러한 변화는 특히 팀을 떠나는 경우에 중요합니다. moduleResolution: node 뒤에 하지만 아직 ESM 출력 방식을 완전히 수용할 준비가 되지 않았습니다. ESM은 갑작스러운 변화가 아닌 단계적인 접근 방식을 제공합니다.

The --stableTypeOrdering 7.0 순서 지정을 에뮬레이션하는 플래그

TypeScript 7.0에 포함될 주요 아키텍처 개선 사항 중 하나는 병렬 타입 검사입니다.여러 검사기를 병렬로 실행하면 프로그램의 각 부분을 서로 다른 순서로 검사할 수 있습니다. 타입 ID와 심볼 순서가 검사 순서에 따라 달라지는 경우, 비결정적인 합집합 순서, 속성 순서, 심지어는 드물지만 진단 결과에도 차이가 발생할 수 있습니다.

이전 TypeScript 버전에서는 발생 순서에 따라 내부 유형 ID를 할당합니다.이러한 ID는 공용체 유형이나 속성 등을 정렬하는 데 사용됩니다. 따라서 새로운 항목을 추가하는 것과 같이 겉보기에는 무해해 보이는 편집 작업도 문제가 될 수 있습니다. const 기존 함수 이전에—생성된 리터럴 합집합의 순서를 바꿀 수 있습니다. .d.ts 파일을 수정하거나 편집기에서 특정 유형의 출력 방식을 변경할 수 있습니다.

TypeScript 7.0에서는 내부 객체에 대해 내용 기반의 결정론적 순서 지정 방식을 채택했습니다.모든 타입이나 심볼은 방문 순서가 아닌 구조에 따라 정렬되므로, 동일한 프로그램은 병렬 처리 여부나 컴파일 순서에 관계없이 항상 동일한 순서를 생성합니다. 따라서 "왜 UNION 연산 결과가 갑자기 바뀌었지?"와 같은 의문이 사라집니다.

6.0과 7.0의 동작 방식을 비교하는 데 도움이 되도록 RC 버전에서는 다음과 같은 기능을 도입했습니다. --stableTypeOrdering이 플래그를 활성화하면 TypeScript 6.0은 7.0에서 사용하는 것과 동일한 결정론적 타입 순서 지정 알고리즘을 채택합니다. 그 결과, 생성되는 선언 파일의 차이점이 훨씬 줄어들고 6.x와 7.x 출력 간의 비교가 더욱 예측 가능해집니다.

하지만 결정론은 자유로운 것이 아닙니다.. 활성화 --stableTypeOrdering 이 설정은 코드베이스에 따라 타입 검사 속도를 최대 약 25%까지 저하시킬 수 있습니다. 이는 진단 및 마이그레이션 지원을 위한 것이며, 상시 활성화하는 성능 향상 설정이 아닙니다.

만약 다음과 같은 경우에만 입력 오류가 발생한다면 --stableTypeOrdering 켜져있다이는 일반적으로 이전 코드가 타입 추론을 위해 우연에 맡겨진 기존 방식에 의존하여 "그냥 작동"하도록 만들어졌음을 의미합니다. 해결 방법은 대개 타입을 명시적으로 지정하는 것입니다. 예를 들어 문제가 있는 제네릭 호출에 타입 인수를 추가하거나, 복잡한 객체에 대해 추론에만 의존하는 대신 특정 인터페이스로 변수에 주석을 다는 것입니다.

New es2025 대상 및 라이브러리 옵션

TypeScript 6.0은 다음을 추가합니다. es2025 두 가지 모두에 대한 옵션 target libES2025는 이전 버전과 비교하여 새로운 핵심 구문을 도입하지는 않았지만, 이전에는 접근이 제한되었던 여러 표준화된 API를 통합했습니다. esnext.

대상으로 삼거나 포함함으로써 es2025그러면 새로운 내장 함수에 대한 업데이트된 타입 정의를 얻을 수 있습니다. 처럼 RegExp.escape그리고 일부 API는 다른 곳으로 이동되었습니다. esnext 으로 es2025여기에는 다음과 같은 것들이 포함됩니다. Promise.try이터레이터 도우미 및 기타 Set 완전한 사양 성숙도에 도달한 방법들. 이 연구는 모리우치 켄타가 기여했습니다.

더 넓은 관점에서 보면, 기본값은 target 6.0 버전부터는 현재 ECMAScript 연도를 추적합니다.현재로서는 대상을 지정하지 않으면 사실상 ES2025로 연결됩니다. 이는 상시 실행되는 런타임과 최신 도구의 현실에 더 부합합니다.

Temporal API용 내장 유형

오랫동안 기다려온 시간적 제안이 3단계에 진입했으며, 악명 높았던 기존 제안을 대체할 것으로 예상됩니다. Date 중요한 날짜/시간 작업을 위한 APITypeScript 6.0에서는 Temporal에 대한 기본 타입 정의가 제공되므로, 완벽한 타입 안정성과 에디터 지원을 통해 Temporal 기반 코드를 작성할 수 있습니다.

시간 유형을 활성화하려면 다음을 사용할 수 있습니다. --target esnext 또는 라이브러리를 명시적으로 구성하십시오. 다음과 같은 방식으로:

{
  "compilerOptions": {
    "lib": 
  }
}

또는 시간적 하위 집합만 선택할 수도 있습니다. "esnext.temporal" 보다 세부적인 설정을 원하시면 다음과 같은 코드를 작성할 수 있습니다. 활성화 후에는 다음과 같은 코드를 작성할 수 있습니다.

let yesterday = Temporal.Now.instant().subtract({
  hours: 24,
});

let tomorrow = Temporal.Now.instant().add({
  hours: 24,
});

console.log(`Yesterday: ${yesterday}`);
console.log(`Tomorrow: ${tomorrow}`);

시간적 특성은 일부 런타임에서 이미 지원되며, 다른 런타임에서는 폴리필을 통해 구현할 수 있습니다.따라서 이러한 타입들은 오늘날 실제로 사용 가능합니다. MDN에 관련 문서가 점차 올라오고 있으며 (아직 일부 부족한 부분이 있지만), GitHub 사용자 Renegade334가 타입 정의에 기여했습니다.

업서트 지원: Map.getOrInsert getOrInsertComputed

자바스크립트 개발자들은 "확인 후 설정 후 가져오기" 패턴을 수동으로 작성해 왔습니다. Map 수년간일반적인 패턴은 키가 존재하는지 확인하고, 존재하지 않으면 기본값을 설정한 다음, 마지막으로 값을 반환합니다. 이러한 정형화된 코드는 잘못 작성하기 쉽고, 모든 곳에서 반복될 수 있습니다.

ECMAScript "업서트" 제안(현재 4단계)은 다음을 도입합니다. getOrInsert getOrInsertComputed on Map WeakMapTypeScript 6.0에서는 이러한 메서드에 대한 타입 지원이 추가되었습니다. esnext lib를 사용하면 선언적인 upsert 구문을 바로 작성할 수 있습니다.

와 getOrInsert이처럼 장황한 패턴:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue: unknown;
  if (compilerOptions.has("strict")) {
    strictValue = compilerOptions.get("strict");
  } else {
    strictValue = true;
    compilerOptions.set("strict", strictValue);
  }
  // ...
}

한 줄로 줄일 수 있습니다.:

function processOptions(compilerOptions: Map<string, unknown>) {
  let strictValue = compilerOptions.getOrInsert("strict", true);
  // ...
}

동반자 getOrInsertComputed 고가의 채무 불이행에 이상적입니다.—이 메서드는 키가 없는 경우에만 호출되는 콜백 함수를 인수로 받습니다. 이 콜백 함수는 키를 매개변수로 받을 수도 있어 키 자체에서 기본값을 유추할 수 있습니다. TypeScript의 타입 정의는 Renegade334의 기여 덕분에 이러한 동작을 정확하게 포착합니다.

RegExp.escape 더욱 안전한 정규 표현식 구축

사용자가 입력한 문자열을 정규 표현식에 연결해 본 경험이 있다면, 특수 문자를 먼저 이스케이프해야 한다는 것을 알고 있을 것입니다.하지만 대부분의 코드베이스는 헬퍼 함수에서 이스케이핑을 다시 구현하거나 아예 이스케이핑을 생략합니다. 정규 표현식 이스케이핑 제안(현재 4단계)은 이를 표준화합니다. RegExp.escape.

TypeScript 6.0은 다음을 위한 타입을 노출합니다. RegExp.escape 아래 es2025 lib즉, ES2025를 대상으로 하거나 포함할 때 다음과 같은 헬퍼 함수를 ​​안전하게 작성할 수 있습니다.

function matchWholeWord(word: string, text: string) {
  const escapedWord = RegExp.escape(word);
  const regex = new RegExp(`\\b${escapedWord}\\b`, "g");
  return text.match(regex);
}

이제 더 이상 손으로 돌리는 이스케이프 기능이 필요 없습니다.TypeScript는 해당 API를 완벽하게 이해하고 타입 검사를 수행합니다. 이 기능은 ES2025 목표 설정 작업과 마찬가지로 Kenta Moriuchi의 작품입니다.

dom 이제 라이브러리에는 반복 및 비동기 반복 API가 포함되어 있습니다.

역사적으로 TypeScript는 DOM 반복자 지원을 다음과 같이 분리했습니다. dom, dom.iterable글렌데일 dom.asynciterable반복문을 사용하고 싶다면 NodeList or HTMLCollection 과 for...of추가하는 것을 잊지 말아야 했습니다. dom.iterable 귀하의 "lib" 구성과 함께 dom이는 특히 모든 최신 브라우저가 DOM 컬렉션에서 반복 가능한 객체와 비동기 반복 가능한 객체를 지원하기 때문에 흔히 혼란을 야기하는 원인이었습니다.

타입스크립트 6.0에서는, lib.dom.iterable.d.ts lib.dom.asynciterable.d.ts 효과적으로 통합됩니다 lib.dom.d.ts. 즉, 사용하는 것을 의미합니다 "dom" alone은 이제 기본적으로 반복 가능 및 비동기 반복 가능 동작을 제공합니다.

그래도 언급할 수 있습니다 dom.iterable dom.asynciterable 귀하의 tsconfig하지만 이제 그 파일들은 텅 빈 껍데기일 뿐입니다. 이전 설정이 다음과 같았다면:

{
  "compilerOptions": {
    "lib": 
  }
}

안전하게 간단하게 만들 수 있습니다. "dom"그리고 DOM 컬렉션에 대한 반복문은 다음과 같습니다. document.querySelectorAll("div") 여전히 타입 검사를 수행합니다.

for (const element of document.querySelectorAll("div")) {
  console.log(element.textContent);
}

이는 작지만 반가운 청소 작업입니다. 이는 기본 DOM 라이브러리를 최신 브라우저의 현실에 맞춰 조정하고 프로젝트 설정 과정에서 발생할 수 있는 또 다른 문제점을 제거합니다.

TypeScript 6.0의 기본 설정, 사용 중단 예정 사항 및 호환성이 깨지는 변경 사항

새로운 API 외에도, 6.0 버전은 1.0 버전 이후 TypeScript의 기본 설정에 가장 과감한 변화를 가져왔습니다.이러한 변화는 현재의 자바스크립트 생태계를 반영합니다. 즉, 상시 사용 가능한 런타임, ESM을 기본으로 하는 아키텍처, 번들러의 광범위한 사용, 그리고 엄격한 타입 지정과 성능에 대한 강한 요구 등을 반영합니다.

이 팀은 이러한 결정의 근간이 되는 몇 가지 광범위한 추세를 강조합니다.ES5와 진정한 레거시 브라우저는 거의 사라졌고, AMD/UMD 모듈 시스템은 틈새시장이며, 이제 거의 모든 것이 모듈 형태로 제공되고, 엄격한 타입 검사가 표준이 되었으며, 특히 7.0 버전에서 병렬 검사가 도입됨에 따라 성능이 최우선 과제로 남게 되었습니다.

결과적으로 TypeScript 6.0 및 7.0은 최신 기본 설정을 지향하고 "레거시 방식 유지 장치"를 줄이는 방향으로 개발되고 있습니다.6.0 RC 버전에서는 설정을 통해 일시적으로 사용 중단 알림을 숨길 수 있습니다. "ignoreDeprecations": "6.0" 귀하의 tsconfig하지만 이러한 옵션은 7.0 버전에서는 제공되지 않습니다. 일부 조정은 실험적인 도구와 같은 도구를 사용하여 자동화할 수 있습니다. ts5to6 codemod는 다음과 같은 것들을 다시 작성하는 데 도움을 줄 수 있습니다. baseUrl rootDir 프로젝트 전체의 구성.

많은 프로젝트에서 즉시 필요한 두 가지 조정 사항

사용 중단 예정인 기능 목록은 길지만, 그중에서도 두 가지 설정 변경 사항이 가장 많은 코드베이스에 영향을 미칠 가능성이 높습니다.:

• 명시적으로 설정하세요 types 정렬 (매우 자주) (테스트 프레임워크도 포함해야 합니다.) 이것이 없으면 자동 포함되는 주변 유형이 사라집니다. @types/*.
• 명시적으로 설정됨 rootDir (천하게 "./src") 기존의 "공통 루트 추론" 방식에 의존했다면 문제가 발생할 수 있습니다. 그렇지 않으면 생성되는 파일 구조가 미묘하게 달라질 수 있습니다.

실종 증상 types 전역 변수에 대한 수많은 오류를 포함합니다. process, fs, path및 describe 정의되지 않음변화의 증상 rootDir 이는 출력 경로가 예상치 못하게 추가적인 이점을 얻는 것과 더 관련이 있습니다. src 세그먼트(예시) dist/src/index.js 대신 dist/index.js).

최신 프로젝트에 맞게 기본 설정이 업데이트되었습니다.

이제 몇몇 컴파일러 옵션에 대부분의 새 앱이 실제로 빌드되는 방식과 일치하는 새로운 기본값이 적용되었습니다.:

• strict 이제 기본값은 다음과 같습니다. true엄격 모드는 더 이상 선택 사항이 아니라 기본 설정입니다. 이전에 비엄격 모드를 사용했다면 명시적으로 설정해야 합니다. "strict": false (하지만 그렇게 하면 중요한 안전 점검 항목들을 놓치게 될 것입니다.)
• module 이제 기본값은 다음과 같습니다. esnext이는 ESM이 지배적인 모듈 형식이며 번들러 및 최신 Node.js와 가장 잘 호환된다는 점을 반영합니다.
• target 현재 ECMAScript 연도(현재는 사실상 ES2025)를 기본값으로 사용합니다.대부분의 배포는 상시 운영 환경을 대상으로 하거나, 정말 필요한 경우 더 낮은 수준으로 다운그레이드할 수 있는 번들러를 거친다는 점을 인정합니다.
• noUncheckedSideEffectImports 지금 true 기본적으로이는 부작용만을 위해 포함된 임포트에서 오타나 잘못된 경로를 잡아내는 데 도움이 됩니다.
• libReplacement 기본값은 false이를 통해 프로젝트가 특수 라이브러리 동작을 명시적으로 선택할 때까지 발생하는 수많은 추가 모듈 해결 실패 및 감시 오버헤드를 방지할 수 있습니다.

이러한 새로운 기본 설정 중 어느 하나라도 빌드에 문제를 일으키는 경우, 모든 설정은 명시적으로 재정의할 수 있습니다. tsconfig.json하지만 그 의도는 새로운 프로젝트가 추가 설정 없이 "그냥 올바른 일을 하도록" 하는 것입니다.

rootDir 이제 기본값은 설정 디렉터리입니다.

이전에는, 만약 당신이 지정하지 않았다면 rootDirTypeScript는 공통 소스 루트를 추론하려고 시도했습니다. 프로그램 내의 선언 파일을 제외한 모든 파일을 기반으로 했습니다. 이로 인해 프로젝트 경계를 파악하기가 더 어려워졌고, emit 함수가 어디에 위치해야 하는지 결정하기 위해 수많은 파일 경로를 살펴봐야 했습니다.

TypeScript 6.0에서 기본값은 rootDir 이것은 단순히 포함된 디렉토리입니다. tsconfig.json기존 추론 동작은 실행할 때만 적용됩니다. tsc 명령줄에서 아무것도 없이 tsconfig 천만에.

이번 변경 사항은 소스 파일이 구성 디렉터리보다 더 깊은 곳에 있는 프로젝트의 경우 명시적으로 설정해야 함을 의미합니다. rootDir일반적인 구성은 다음과 같습니다.

{
  "compilerOptions": {
    // ...
    "rootDir": "./src"
  },
  "include": 
}

설정 파일에서 위의 파일을 참조하는 경우 tsconfig 위치를 변경하려면 추가 조치가 필요합니다. rootDir 따라서예를 들어, "rootDir": "../src" 공유 소스 디렉터리의 경우.

types 이제 기본값은 빈 배열입니다.

이는 실제 프로젝트에 가장 큰 영향을 미치는 변화라고 할 수 있습니다.역사적으로, 명시하지 않으면 types in compilerOptionsTypeScript는 아래의 모든 것을 자동으로 포함합니다. node_modules/@types그건 편리했지만 비용이 많이 들고 취약했습니다. 현대의 저장소는 종종 수백 개의 저장소를 가져옵니다. @types 패키지를 전이적으로 사용합니다.

타입스크립트 6.0에서는, types 기본값은 []즉, 주변 환경 유형 패키지가 자동으로 로드되지 않습니다.이제 실제로 필요한 글로벌 환경을 명시적으로 선택할 수 있습니다. 예를 들면 다음과 같습니다.

{
  "compilerOptions": {
    "types": 
  }
}

이를 통해 일부 프로젝트의 제작 시간을 20~50% 단축할 수 있습니다.컴파일러가 더 이상 모든 선언 파일을 샅샅이 뒤질 필요가 없기 때문입니다. @types만약 예전처럼 "모든 것을 로드"하는 동작을 원하신다면 다음과 같이 지정할 수 있습니다.

{
  "compilerOptions": {
    "types": 
  }
}

"Cannot find name 'process'" 또는 "Cannot find module 'fs'"와 같은 오류 메시지가 갑자기 나타나는 경우자, 이제 추가할 차례입니다. node (그리고 여러분이 의존하는 다른 모든 테스트/런타임 유형)을 여러분의 것으로 types 정렬.

사용되지 않음 : target: es5 --downlevelIteration

ES5를 대상으로 하는 것은 이제 더 이상 사용되지 않습니다.주요 브라우저들이 이미 수년 전부터 ES2015 이상을 지원하고 인터넷 익스플로러도 단종됨에 따라, 타입스크립트 자체 내에서 ES5 출력을 구현하는 것은 더 이상 복잡성을 감수할 가치가 없다고 여겨집니다. 향후 지원되는 최소 대상 버전은 ES2015입니다. 만약 정말로 ES5를 사용해야 한다면, 타입스크립트 소스 코드 또는 출력 코드에 외부 트랜스파일러(예: Babel 또는 번들러 파이프라인)를 사용하는 것이 좋습니다.

The --downlevelIteration 플래그도 더 이상 사용되지 않습니다.왜냐하면 그 유일한 의미 있는 사용 사례는 ES5 타겟에 맞춰 emit 동작을 조정하는 것이었기 때문입니다. TypeScript 6.0에서는 설정 downlevelIteration 전혀 사용하지 않으면 사용 중단 오류가 발생합니다. ES2015 이상 버전을 사용하는 경우 해당 플래그는 애초에 아무런 효과가 없었습니다.

사용되지 않음 : --moduleResolution node 그리고 유산 classic

The node (일명 node10모듈 해상도 모드는 더 이상 사용되지 않습니다.이 버전은 Node 10의 동작을 모방했지만 최신 Node의 ESM 및 해상도 의미 체계와는 일치하지 않습니다. 프로젝트는 다음 버전 중 하나로 마이그레이션해야 합니다. nodenext (직접적인 노드 대상의 경우) 또는 bundler (웹 앱이나 Bun과 같은 번들러 기반 환경의 경우)

원래 moduleResolution: classic 전략도 삭제되었습니다.이것은 Node.js 해결 방식이 도입되기 전 TypeScript의 이야기입니다. 오늘날에는 모든 실제 시나리오가 다음과 같은 방식으로 더 잘 처리됩니다. nodenext or bundler그래서 복잡성과 예외 상황을 줄이기 위해 고전적인 방식은 사라졌습니다.

사용 중단 예정: AMD, UMD, SystemJS 등 module: none

다음 module 해당 값들은 이제 더 이상 사용되지 않으며 사실상 지원되지 않습니다.:

• amd
• umd
• systemjs
• none

이러한 형식들은 ESM 이전 시대에 매우 중요했습니다.브라우저에 기본 모듈 지원이 부족했던 시절에는 개발자들이 AMD, UMD 또는 SystemJS를 활용하여 그 공백을 메웠습니다. 오늘날에는 ESM과 번들러 또는 임포트 맵이 거의 모든 실제 사용 사례를 처리하며, "없음"이라는 표현은 애초에 명확하게 정의된 적이 없었습니다.

여전히 이러한 기존 모듈 형식을 대상으로 하는 경우권장 사항은 ESM을 생성하는 대상으로 마이그레이션하고 최종 패키징을 위해 번들러 또는 대체 컴파일러를 사용하거나, 마이그레이션 계획이 수립될 때까지 TypeScript 5.x를 유지하는 것입니다. 이러한 정리 작업의 일환으로 기존 코드는 삭제됩니다. amd-module 해당 지침도 삭제되었습니다.

사용되지 않음 : baseUrl

The baseUrl 이 옵션은 오랫동안 디버깅하기 어려운 이상한 모듈 해결 동작의 원인이 되어 왔습니다.많은 프로젝트에서 이를 단순히 접두사로 사용했습니다. paths 항목뿐만 아니라 TypeScript는 이를 일반적인 조회 루트로도 취급하여 다음과 같은 가져오기 오류를 발생시켰습니다. "someModule" 해결하다 src/someModule.js 예상치 못하게, 개발자는 단지 사용자 지정 별칭을 지원하려고 했을 뿐인데 @app/*.

6.0년에 baseUrl 이 기능은 더 이상 사용되지 않으며 조회 루트로 사용되지 않습니다.경로 매핑은 필요하지 않았습니다. baseUrl 꽤 오랜 기간 동안 그래왔기 때문에 권장되는 마이그레이션 방법은 접두사를 각각에 통합하는 것입니다. paths 입력. 예를 들면:

// Before
{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

// After
{
  "compilerOptions": {
    "paths": {
      "@app/*": ,
      "@lib/*": 
    }
  }
}

정말로 사용한 경우는 극히 드뭅니다. baseUrl 일반적인 조회 루트로서 다음과 같은 포괄적인 경로 매핑을 사용하여 해당 동작을 재현해야 합니까?

"paths": {
  "*": ,
  "@app/*": ,
  "@lib/*": 
}

대부분의 팀에게 단순히 제거하는 것은... baseUrl 그리고 인라인 접두사 paths 더욱 명확하고 안전해질 것입니다..

상호 운용성과 엄격성: esModuleInterop, allowSyntheticDefaultImports글렌데일 alwaysStrict

TypeScript 6.0은 또한 오랫동안 권장되어 온 기본 상호 운용 동작을 확정합니다.더 이상 설정할 수 없습니다. esModuleInterop or allowSyntheticDefaultImports 에 false이러한 옵션은 원래 기존 프로젝트와의 호환성을 유지하기 위해 선택 사항이었지만, 현재는 이 옵션을 비활성화하면 CommonJS와 ESM을 함께 사용할 때 미묘한 런타임 문제가 발생하는 경우가 많습니다.

상호 운용성이 항상 활성화된 경우 특정 가져오기 패턴을 업데이트해야 할 수 있습니다.. 예를 들면 :

// Old style with esModuleInterop: false
import * as express from "express";

// New style with modern interop always on
import express from "express";

The alwaysStrict 플래그도 설정할 수 없습니다. false 더 이상TypeScript는 이제 예약어 및 기타 사항을 포함하여 모든 부분에서 JavaScript 엄격 모드 의미론을 전반적으로 가정합니다. this 예의를 지키세요. 만약 예약어를 사용하는 아주 오래된 코드가 있다면, 예를 들어 다음과 같은 단어를 사용했을 수 있습니다. await or static 식별자로 사용하려면 이름을 변경해야 합니다.

사용되지 않음 : outFile레거시 네임스페이스 module 키워드 및 가져오기 asserts

The --outFile 해당 옵션은 6.0 버전에서 제거되었습니다.여러 입력을 하나의 JS 번들로 결합하는 작업은 Webpack, Rollup, esbuild, Vite, Parcel 또는 이와 유사한 도구를 사용하는 것이 더 적합합니다. TypeScript는 번들러 역할을 하기보다는 타입 검사와 선언 생성에 더욱 집중하고 있습니다.

기존 사용 module 네임스페이스를 선언하는 것은 이제 심각한 오류입니다.초기 TypeScript 사용이 허용되었습니다.

module Foo {
  export const bar = 10;
}

최신 지원 구문은 다음을 사용합니다. namespace:

namespace Foo {
  export const bar = 10;
}

이러한 변경은 향후 ECMAScript와의 충돌을 방지하기 위해 필요합니다. module 블록주변 모듈 선언은 다음과 같습니다. declare module "some-module" { ... } 전폭적인 지지를 보냅니다.

가져오기 어설션을 사용하여 asserts 또한 사용이 권장되지 않습니다.기본 제안이 가져오기 속성을 사용하는 방식으로 발전했기 때문입니다. with코드는 다음과 같습니다:

import blob from "./data.json" asserts { type: "json" };

새로운 형태로 마이그레이션되어야 합니다.:

import blob from "./data.json" with { type: "json" };

사용되지 않음 : no-default-lib tsconfig를 사용한 참조 및 명령줄 파일 목록

The /// <reference no-default-lib="true" /> 해당 지침은 더 이상 지원되지 않습니다.이는 종종 오해되었습니다. 기본 라이브러리를 제외해야 하는 경우 다음을 사용하십시오. --noLib or --libReplacement 대신, 구성 수준에서 의도를 더욱 명확하게 표현하는 방식입니다.

또 다른 오랜 혼란의 원인은 바로 이것입니다. tsc 명시적인 파일 인수를 처리할 때 tsconfig.json 존재함이전에는 실행 중이었습니다. tsc foo.ts 이러한 디렉터리에서는 구성 파일을 아무런 경고 없이 무시합니다. 하지만 6.0 버전에서는 이러한 시나리오에서 명시적인 오류가 발생합니다.

error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.

설정을 완전히 건너뛰고 기본 설정으로 단일 파일만 컴파일하고 싶다면, 이제 사용할 수 있습니다. tsc --ignoreConfig foo.ts 그러한 의도를 명확히 하기 위해서입니다.

타입스크립트 7.0 출시 준비 중

TypeScript 6.0은 기능 개발이 완료되었으며 대부분 안정화 단계에 있습니다.정식 출시 전까지는 중요한 버그 수정만 진행될 것으로 예상됩니다. 야간 빌드는 정기적으로 게시되며, 개발팀은 곧 출시될 네이티브(Go 기반) TypeScript 7.0의 야간 빌드 버전과 새로운 엔진을 시험해 볼 수 있는 VS Code 확장 프로그램도 함께 제공합니다.

로드맵은 의도적으로 빠듯하게 짜여 있습니다. 7.0 버전은 6.0 버전 출시 직후에 나올 것으로 예상됩니다.따라서 업그레이드 과정의 어려움과 마이그레이션 문제에 대한 피드백 주기가 짧아질 것입니다. 6.0 버전에서 사용 중단 경고가 표시되는 경우, 7.0 버전에서 문제가 발생할 때까지 기다리지 말고 지금 바로 해결하는 것이 좋습니다.

대부분의 팀에서 실제로 사용하는 워크플로는 다음과 같습니다.TypeScript 6.0 RC로 업그레이드하고 문제를 해결하세요. types rootDir사용 중단 대상을 지정하거나 (일시적으로 사용을 제한할 수도 있습니다) "ignoreDeprecations": "6.0" 반복하는 동안) 그리고 실행하세요 --stableTypeOrdering 7.0의 결정론적 순서 지정을 위해 출력을 비교하거나 CI 파이프라인을 준비해야 하는 경우입니다. 일단 이 작업이 완료되면 Go 기반 컴파일러로의 전환은 코드 변경보다는 성능 향상처럼 느껴질 것입니다.

종합적으로 볼 때, TypeScript 6.0 RC는 화려한 구문보다는 미래를 위한 토대를 마련하는 데 더 중점을 두고 있습니다.7.0 버전에서는 네이티브 수준의 속도, 깔끔한 설정, 최신 기본 설정, 그리고 Temporal 및 ES2025 내장 함수와 같은 표준화된 API를 통해 일상적인 코딩이 훨씬 쉬워집니다. 지금 도입하고, 불필요한 부분을 수정하고, 새로운 기본 설정을 적극적으로 활용하면 네이티브 컴파일러가 출시될 때 훨씬 유리한 위치에 있게 될 것입니다.