타입스크립트 7.1 베타, 기존 컴파일러 API 코드는 무엇을 바꿔야 할까?
TypeScript 7.1 베타로 앱의 타입 검사는 통과했는데, 같은 프로젝트의 코드 생성기는 실행되지 않는다. tsc는 되는데 컴파일러 API를 쓰는 도구만 멈추는 이유는 뭘까?
- TypeScript 7.1 베타는 새 컴파일러 API를 제공하지만 6.x API의 교체용 호환판은 아니다.
- 도구 작성자는 import 경로와 API·Program 자원의 수명을 새 구조에 맞춰야 한다.
- 도구를 설치해 쓰는 팀은 그 도구의 지원 버전을 확인해야 한다. tsc 실행 성공만으로 플러그인 호환까지 판단할 수 없다.
7.1을 설치하는 것만으로 옛 API 코드가 옮겨지지는 않는다
import * as ts from "typescript"로 시작해 ts.createProgram()을 호출하는 도구라면, TypeScript 버전만 올리는 것으로 전환을 끝낼 수 없다. Microsoft의 기존 Compiler API 안내도 해당 예제가 6.0 이하를 대상으로 하며 7.1은 다른 API를 사용한다고 명시한다.
10월 20일 공개된 7.1 베타는 네이티브 컴파일러를 코드에서 사용할 새 인터페이스를 제공한다. 타입 검사 명령을 실행하는 개발자보다, 컴파일러를 불러 코드 생성·분석·변환을 수행하는 도구 제작자에게 더 직접적인 변화다.
예컨대 애플리케이션의 타입 검사는 끝나는데 별도 코드 생성기가 실행되지 않는다면 두 작업을 나눠 봐야 한다. 앞의 작업은 명령행 컴파일러를 쓰고, 뒤의 작업은 옛 자바스크립트 API를 가져와 호출할 수 있다. 이 경우 고칠 대상은 앱의 모든 타입 선언이 아니라 코드 생성기의 컴파일러 연동 부분이다.
동기·비동기 호출과 AST 도구의 import 경로가 나뉜다
7.1에서는 필요한 역할에 맞춰 진입점을 선택한다. 컴파일러 API 클라이언트와 구문 트리 도구를 하나의 ts 객체에서 찾던 코드는 이 경계를 기준으로 옮긴다.
| 필요한 작업 | 새 진입점 |
|---|---|
| 동기 방식의 컴파일러 호출 | typescript/sync |
| Promise 기반 컴파일러 호출 | typescript/async |
| 파일 시스템 구성 | typescript/fs |
| AST 타입·열거형, 노드 검사·생성 | typescript/ast, typescript/ast/is, typescript/ast/factory |
공식 비동기 API 구현에서도 createProgram은 루트 파일과 컴파일러 옵션을 받아 Promise<Program>을 반환한다. 기존 동기 호출 코드의 import만 바꾸고 반환값을 곧바로 Program처럼 쓰는 전환은 맞지 않는다. 도구의 실행 흐름에 맞는 진입점을 먼저 고른다.
API와 Program은 사용이 끝나는 지점을 정해야 한다
새 API의 중요한 변경은 자원 해제다. Microsoft는 API와 Program을 자바스크립트 가비지 컬렉터에만 맡기면 Go 쪽 자원이 남을 수 있다고 설명한다. 동기 API는 using이나 명시적 해제로 수명을 관리한다. 비동기 API는 await using을 쓰거나 해제 메서드가 반환하는 Promise가 끝날 때까지 기다려야 한다.
동기 자원을 다루는 using 선언은 변수가 속한 블록을 벗어날 때 객체의 Symbol.dispose 메서드를 호출한다. 같은 범위에 여러 자원을 선언하면 선언의 역순으로 정리하며, 중간에 예외가 발생해도 해제를 수행한다. API를 먼저 만들고 Program을 그다음 만들었다면 Program을 먼저 정리하는 흐름을 만들 수 있다.
도구 설계에서는 한 번의 분석 작업이 끝나는 지점을 정하는 데 이 규칙을 적용한다. 해제된 Program을 캐시에 보관해 다음 요청에서 다시 쓰는 구조는 피해야 한다. 오래 실행되는 서버나 편집기 연동 도구라면 객체를 만드는 부분뿐 아니라 보관하고 버리는 부분도 함께 수정해야 한다.
직접 만든 도구와 설치한 도구는 전환 방법이 다르다
직접 작성한 API 코드는 호출·설정·수명을 옮겨야 하고, 외부 도구는 해당 제작자가 제공하는 지원 경로를 따라야 한다. 다음 구분은 새 API의 변경점을 기존 프로젝트에 적용하는 순서다.
- 직접 호출하는 코드부터 찾는다.
createProgram,transpileModule, AST 접근처럼 TypeScript를 라이브러리로 사용하는 부분을 명령행 검사와 분리한다. - 설정 파일을 누가 읽는지 확인한다. 7.1 발표의 간단한 컴파일 예제는 파일명·옵션을 직접 받고
tsconfig.json검색·로드나--project를 구현하지 않는다. 예제를 가져왔다고 기존 설정이 자동 적용되는 것은 아니다. - 생성 결과와 진단을 기존 작업과 대조한다. 타입 검사 외에 코드 생성·린트·프레임워크 빌드를 각각 실행해, 실제로 사용하는 연동이 동작하는지 판단한다.
전환을 기다리는 도구가 있다면 7.0 발표가 제시한 6.0 병행 경로도 참고할 수 있다. @typescript/typescript6은 옛 API와 tsc6 실행 파일을 제공한다. 다만 도구가 typescript라는 이름을 직접 불러오는지에 따라 패키지 별칭 등 연결 방법이 달라진다.
7.1 베타는 도구 제작자가 네이티브 컴파일러로 옮길 길을 제공한다. 프로젝트에서 전환이 끝났다는 판단은 사용 중인 도구의 실제 연동까지 확인한 뒤 내려야 한다.