Babel과 TypeScript 함께 쓰기

TypeScript 파일을 JavaScript로 바꿀 방법을 고르다 보면, 'Babel을 쓸까, tsc를 쓸까?' 하는 질문에 마주치게 돼요. 둘을 어떻게 나눠 쓰는지, 그리고 타입 검사는 어느 쪽이 맡는지 함께 살펴볼게요.

출처: TypeScript 핸드북 - Using Babel with TypeScript

TypeScript를 위한 Babel vs `tsc`

현대적인 JavaScript 프로젝트를 만들 때, TypeScript 파일에서 JavaScript 파일로 변환하는 올바른 방법이 무엇인지 궁금할 거예요.

많은 경우 답은 "상황에 따라 다릅니다" 또는 프로젝트에 따라 "누군가 이미 정해 놓았을 수도 있습니다" 가 돼요. tsdx, Angular, NestJS 같은 기존 프레임워크나 Getting Started에 언급된 프레임워크로 프로젝트를 빌드한다면, 이 결정은 이미 처리되어 있어요.

하지만 유용한 경험칙(heuristic)은 이렇습니다.

빌드 출력이 소스 입력 파일과 대체로 같나요? 그러면 tsc를 쓰세요.
여러 가능한 출력이 있는 빌드 파이프라인이 필요한가요? 그러면 트랜스파일에는 babel을, 타입 검사에는 tsc를 쓰세요.

트랜스파일은 Babel로, 타입은 `tsc`로

이것은 기존 빌드 인프라를 가진 프로젝트에서 흔한 패턴이에요. JavaScript 코드베이스에서 TypeScript로 포팅된 경우가 많죠.

이 기법은 하이브리드 접근 방식이에요. Babel의 preset-typescript로 JS 파일을 만들고, TypeScript로 타입 검사와 .d.ts 파일 생성을 수행합니다.

Babel의 TypeScript 지원을 사용하면 기존 빌드 파이프라인과 함께 동작할 수 있고, JS 출력(emit) 시간이 더 빨라질 가능성이 커요. Babel은 코드를 타입 검사하지 않기 때문이에요.

타입 검사와 d.ts 파일 생성

Babel을 사용할 때의 단점은 TS에서 JS로 전환하는 동안 타입 검사를 받지 못한다는 거예요. 이는 에디터에서 놓친 타입 오류가 운영 코드까지 새어 들어갈 수 있다는 뜻이에요.

게다가 Babel은 .d.ts 파일을 생성하지 못해요. 프로젝트가 라이브러리라면 작업하기가 더 어려워질 수 있죠.

이 문제들을 해결하려면, TSC로 프로젝트를 타입 검사하는 커맨드를 설정하면 좋을 거예요. 아마도 Babel 설정 중 일부를 상응하는 tsconfig.json으로 복제하고, 이 플래그들이 켜져 있는지 확인하는 것을 의미할 거예요.

"compilerOptions": {
  // Ensure that .d.ts files are created by tsc, but not .js files
  "declaration": true,
  "emitDeclarationOnly": true,
  // Ensure that Babel can safely transpile files in the TypeScript project
  "isolatedModules": true
}

이 플래그들에 대한 더 자세한 정보:

더 알아보기 (Learn more)

tsconfig.json에서 이 가이드가 언급한 플래그들을 더 자세히 살펴보세요.
Babel의 preset-typescript 문서를 읽어 보세요.

Babel과 TypeScript 함께 쓰기