타입스크립트의 구성력은 당므을 통해 제공되는 100개 이상의 풍부한구성 옵션에서부터 비롯된다.

• tsc 에 전달된 명령줄 플래그
• 타입스크립트 구성 파일 TSConfig

tsc -- help 를 실행해 일반적으로 사용하는 CLI 플래그 목록을 가져올 수 있다. 전체 구성 옵션 목록은 tsc --all 으로 확인 가능하다.

tsc CLI는 색상과 간격의 슽일을 지정해 가독성을 높이는 pretty 모드를 지원한다. 출력 터미널이 여러 색상 텍스트를 지원한다는 것을 감지하면 기본적으로 pretty 모드로 설정된다.

필자가 tsc CLI 에서 가장 좋아하는 방법은 -w 나 -watch 모드를 사용하는 것이다.

watch 모드를 적용하면 종료하는 대신 타입스크립트를 무기한 실행 상태로 유지하고 모든 오류의 실시간 목록을 가져와서 터미널을 지속적으로 업데이트한다.

모든 파일 이름과 구성 옵션을 항상 tsc 에 제공하는 대신 디렉터리의 tsconfig.json 파일에 구체적으로 명시 가능하다.

tsc 명령줄에는 tsconfig.json 파일을 생성하기 위한 --init 명령이 포함되어야 한다.

tsc --init 에 따라 생성된 TSConfig 파일을 살펴보면 해당 파일의 구성 옵션이 "compilerOptions" 객체 내에 있다. CLI 와 tsconfig 파일에서 사용 가능한 대부분의 옵션은 다음 두 가지 범주 중 하나로 분류된다.

• 컴파일러: 포함된 각 파일이 타입스크립트에 따라 컴파일되거나 타입을 확인하는 방법
• 파일: 타입스크립트가 실행될 파일과 실행되지 않은 파일

기본적으로 tsc 는 현재 디렉터리와 하위 디렉터리에 있는 숨겨지지 않은 모든 .ts 파일에서 실행되고 숨겨진 디렉터리와 node_modules 는 무시한다.

파일을 포함하는 가장 흔한 방법으로 tsconfig.json 의 최상위 "includes" 속성을 사용한다.

예를 들어 다음 구성 파일은 tsconfig.json 과 관련된 src/ 디렉터리 안의 모든 타입스크립트 소스 파일을 재귀적으로 포함한다.

타입스크립트는 기본적으로 확장자가 .ts 의 모든 파일을 읽을 수 있다. 그러나 일부 프로젝트는 JSON 모듈 또는 리엑트와 같은 UI 라이브러리를 위한 JSX 구문처럼 확장자가 다른 파일을 읽을 수 있어야 한다.

같은 JSX 구문은 리엑트 같은 UI 라이브러리에서 자주 사용한다. JSX 구문은 자바스크립트가 아니다. 타입스크립트의 타입 정의와 마찬가지로 자바스크립트로 컴파일되는 자바스크립트 구문의 확장이다.

타입스크립트가 .tsx 파일에 대한 자바스크립트 코드를 내보내는 방법은 "jsx" 컴파일러 옵션에 사용되는 값으로 결정된다. 프로젝트는 [표 13-1]에 있는 세 가지 값 중 하나를 사용한다.

{
  "compilerOptions" : {
    "jsx": "reserve"
  }
}

바벨과 같은 별도의 도구로 코드를 변환하는 것처럼 타입스크립ㅌ의 내장된 트랜스파일러를 직접적으로 사용하지 않을 경우에는 jsx 에 대해 허용된 값을 사용할 수 있다. Next.js 또는 리믹스 와 같은 최신 프레임워크로 구축된 대부분의 웹 앱은 리엑트 구성 및 컴파일 구문을 처리한다. 이러한 프레임워크 중 하나를 사용하면 타입스크립트 내장 트랜스파일러를 직접 구성할 필요가 없다.

제네릭 화살표 함수 구문이 JSX 구문과 충돌한다. .tsx 파일에서 화살표 함수에 대한 타입 인수 를 작성하려고 하면 T 요소의 시작 태그에 대한 종료 태그가 없기 때문에 오류가 발생한다.

const identity = <T>(input: T) => input; // Error

<T = unknown> 이라는 구문을 추가해 해결 가능하다.

타입스크립트는 resolveJsonModule 컴퍼일러 옵션을 true 로설정하면 json 파일을 읽을 수 있다.

json 파일을 마치 객체를 내보내는 .ts 파일인 것처럼 가져오고 해당 객체의 타입을 const 변수인 것처럼 유추한다.

{
  "activist": "Mary";
}

import { activist } from "./activist.json";

console.log(activist); // Ok Logs Mary

esModuleInterop 컴파일러 옵션이 활성화된 경우에도 기본 가져오기를 사용할 수 있다.

import data from "./activist.json";

array 또는 number 같은 리터럴 타입을 포함한 JSON 파일이라면 import 구문으로 * 을 사용한다.

기본적으로 타입스크립트 출력 파일을 해당 소스 파일과 동일한 위치에 생성한다.

경우에 따라 출력 파일을 다른 폴더에 생성하는 것이 더 나을 수 있다.

outDir 컴파일러 옵션을 사용하면 출력 파일의 루트 디렉터리를 다르게 지정 가능하다.

타입스크립트는 ES3 과 같은 오래된 환경에서 실행할 수 있는 자바스크립트 출력 파일을 생성 가능하다.

타입스크립트는 자바스크립트 코드 구문을 지원하기 위해 어느 버전까지 변환해야 하는지를 지정하는 target 컴파일러 옵션을 제공하며

지정하지 않는다면 "es3" 가 기본적으로 지정된다.

tsc --init 은 기본적으로 es2016 을 지정하도록 설정되어 있지만 대상 플랫폼에 따라 가능한 한 최신 자바스크립트 구문을 사용하는것이 좋다.

.d.ts 선언 파일을 패키지로 배포해 사용하는 곳에서 코드 타입을 표시하는 방법을 소개했다.

대부분의 패키지는 타입스크립트의 declaration 컴파일러 옵션을 사용해 소스 파일에서 .d.ts 출력 파일을 내보낸다.

{
  "compilerOptions": {
    "declaration": true
  }
}

.d.ts 출력 파일은 outDir 옵션에 따라 .js 파일과 동일한 출력 규칙을 따라 내보내진다.

declaration 컴파일러 옵션에 대한 특별한 추가로 타입스크립트가 .js 와 .jsx 파일 없이 선언 파일만 내보내도록 지시하는 emitDeclarationOnly 컴파일러 옵션이 있다.

소스 맵은 출력 파일의 내용이 원본 소스 파일과 어떻게 일치하는지에 대한 설명이다.

소스맵은 출력 파일을 탐색할 때 디버거 같은 개발자 도구에서 원본 소스 코드를 표시하도록 설정한다.

타입스크립트 sourceMap 컴파일러 옵션을 사용하면 .js 또는 .jsx 출력 파일과 함께

js.map, jsx.map 소스 맵을 출력 가능하다.

.d.ts 선언 파일에 대한 소스 맵을 생성할 수도 있다. declarationMap 컴파일러 옵션은 원본 소스 파일에 해당하는 각 .d.ts 에 대한 .d.ts.map 소스 맵을 생성하도록 지시한다.

다른 도구를 이용해 소스 파일을 컴파일하고 자바스크립트를 출력하는 프로젝트에서 타입스크립트는 파일 생성을 모두 건너뛰도록 지시 가능하다.

noEmit 컴파일러 옵션을 활성화 하면 타입스크립트가 온전히 타입 검사기로만 작동한다.

대부분의 타입스크립트 구성 옵션은 타입 검사기를 제어한다. 구성 옵션을 느슨하게 구성해 오류가 완전히 확실할 때만 타입 검사 오류를 보고하도록 하거나 구성 옵션을 엄격하게 궁성해 거의 모든 코드를 올바르게 잘 입력하도록 요구할 수 있다.

먼저 타입스크립트가 런타임 환경에 있다고 가정하는 전역 API 는 lib 컴파일러 옵션으로 구성할 수 있다.

{
  "compilerOptions": {
    "lib": ["es2020"]
  }
}

중요

타입스크립트는 소스 코드에 명시적으로 포함되지 않은 선언 파일에서 타입 검사를 건너뛰도록 하는 skipLibCheck 컴파일러 옵션을 제공한다.

skipLibCheck 는 타입 검사 일부를 건너뛰는 작업으로 타입스크립트 성능을 개선한다.

타입스크립트의 타입 검사 컴파일러 옵션 대부분은 타입스크립트의 엄격 모드로 그룹화 된다. 엄격한 컴파일러 옵션은 기본적으로 false 이며 활성화 되면 타입 검사기에 일부 추가적인 검사를 켜도록 지시한다.

특정 검사를 제외한 모든 엄격 모드 검사를 활성화하고 싶다면 strict 를 활성화하고 특정 검사를 명시적으로 비활성화 가능하다.

타입스크립트가 매개변수 또는 속성의 타입을 유추할 수 없는 경우라면 any 타입으로 가정한다. any 타입은 타입스크립트의 타입 검사를 대부분 우회할 수 있으므로 코드에서 이러한 암시적 타입을 허용하지 않는 것이 좋다.

noImplicitAny 컴파일러 옵션은 암시적 any 로 대체될 때 타입스크립트에 타입 검사 오류가 발생하도록 지시한다.

const logMEssage = (message) => {
  // Error Parameter 'message' implicit has an any type
  console.log(`message: ${message}`)
}

타입스크립트가 처음 출시되었을 떄 내장된 Function.apply , bind, call 함수 유틸리티를 나타낼 수 있을 만큼 충분한 타입 시스템이 없었다. 기본적으로 이런 함수는 함수의 인수 목록에 대해 any 를 사용해야 했고 타입 안정성과는 매우 거리가 멀었다.

strictBindCallApply를 활성화 하면 함수 변형에 대해 훨씬 더 정확한 타입을 사용할 수 있다.

strictFunctionTypes 컴파일러 옵션은 함수 매개변수 타입을 약간 더 엄격하게 검사한다.

매개변수가 다른 타입의 매개변수 하위 타입인 경우 함수 타입은 더 이상 다른 함수 타입에 할당 가능한 것으로 간주되지 않는다.

null 과 undefined 같은 비어 있는 타입을 비어 있지 않은 탕비에 할당하도록 허용하는 언어의 십억 달러의 실수에 대해 이야기했다.

타입스크립트의 strictNullChecks 플래그를 비활성화 하면 코드의 모든 타입에 null | undefined 가 추가되고 모든 변수가 null 또는 undefined 를 받을 수 있도록 허용한다.

클래스의 각 속성이 클래스 생성자에 확실하게 할당되었는지를 확인하는 클래스의 엄ㄱ겨한 초기화 검사를 이야기 헀었다.

타입스크립트의 strictPropertyInitialization 플래그는 초기화가 없고 생성자에 확실하게 할당되지 않은 클래스 속성에서 타입 오류를 발생시킨다.

타입스크립트의 모범 사례는 strictPropertyInitialization 를 활성화 시키는 것이다.

모든 언어에서 오류 처리는 본질적으로 안전하지 않은 개념이다. 이론적으로 모든 함수는 사용자가 작성한 throw 문이나 undefined 속성을 읽는 것과 같은 극단적인 경우에 여러 오류를 발생시킨다.

useUnknownInCatchVariables 는 타입스크립트의 기본 catch 절 error 타입을 unknown 으로 변경한다.

AMD, CommonJS, ECMAScript 등 모듈 내용을 내보내고 가져오기 위한 자바스크립트의 다양한 시스템은 최신 프로그래밍 언어에서 가장 복잡한 모듈 시스템이다.

자바스크립트는 파일이 서로의 콘텐츠를 가져오는 방식이 웹펙과 같은 사용자 작성 프레임워크에 따라 구동되는 경우가 많다는 점에서

상대적으로 특이하다. 타입스크립트는 가장 합리적인 사용자 영역 모듈을 구성을 나타내는 구성 옵션을 제공하기 위해 최선을 다한다.

어떤 모듈 시스템으로 변환된 코드를 사용할지 결정하기 위해 module 컴파일 옵션을 제공한다. ECMA 스크립트 모듈로 소스 코드를 작성할 때 타입스크립트는 module 값에 따라 export 와 import 문을 다른 모듈 시스템으로 변환할 수 있다.

target 컴파일러 옵션이 es3, es5 인 경우 module 컴파일러 옵션의 기본값은 commonjs 가 된다.

그렇지 않고 ECMAScript 스크립트 모듈로 출력하도록 지정하기 위해 module 컴파일러 옵션은 es2015 로 기본 설정된다.

자바스크립트 모듈로 작업할 떄 모듈의 기본 내보내기와 네임스페이스 출력 간에는 차이점이 있다. 모듈의 기본 내보내기는 내보낸 객체의 .default 속성이다.

모듈의 네임스페이스 내보내기는 내보낸 객체 자체이다.

타입스크립트의 타입 시스템은 ECMAScript 모듈 측면에서 파일 가져오기와 내보내기에 대한 합의를 만든다.

대부분의 프로젝트처럼 npm 패키지에 의존하는 경우 의존성 중 일부는 여전히 CommonJS 모듈로 배포된다.

타입스크립트에서는 모듈 형식 간의 상호 운용성을 개선하는 몇 가지 컴파일러 옵션을 제공한다.

esModuleInterop 구성 옵션은 module 이 es2015 또는 esnext 와 같은 ECMAScript 모듈 형식이 아닌 경우 타입스크립트에서 내보낸 자바스크립트 코드에 소량의 로직을 추가한다. 해당 로직은 ECMAScript 모듈이 기본 또는 네임스페이스 가져오기에 대한 ECMAScript 모듈의 규칙을 준수하지 않는 경우에도 모듈에서 가져올 수 있도록 한다.

esModuleInterop 를 활성화 하는 이유 중 하나는 기본 내보내기를 제공하지 않는 react 같은 패키지를 위해서이다.

react 패키지에 기본 가져오기를 사용하려고 하면 타입스크립트는e sModuleInterop 이 활성화 되지 않은 것에 대한 타입 오류를 보고한다.

allowSyntheticDefaultImports 컴파일러 옵션은 ECMAScript 모듈이 호환되지 않는 CommonJS 네임스페이스 내보내기 파일에서 기본 가져오기를 할 수 있음을 타입 시스템에 알린다.

allowSyntheticDefaultImports 컴파일러 옵션은 다음 중 하나가 true 인 경우에만 true 로 기본적으로 설정된다.

• module 이 system 일 경우
• esModuleInterop 이 true 이고 module 이 es2015 또는 esnext 와 같은 ECMAScript 모듈 형식이 아닐 경우

한 번에 하나의 파일에서만 작동하는 바벨과 같은 외부 트랜스파일러는 타입 시스템 정보를 사용해 자바스크립트를 내보낼 수 없다. 결과적으로 타입 정보에 의존하며 자바스크립트를 내보내는 타입스크립트 구문 기능은 바벨 같은 트랜스파일러에서는 지원되지 않는다.

• const 열거형
• 스크립트 파일
• 독립 실행형 타입 내보내기

프로젝트에서 타입스크립트가 아닌 다른 도구를 사용해 자바스크립트로 변환하는 경우에는 isolatedModules 를 활성화하는 것이 좋다.

allowJS 컴파일러 옵션은 자바스크립트 파일에 선언된 구문을 타입스크립트 파일에서 타입 검사를 하도록 허용한다.

allowJS가 활성화되어 있지 않으면 import 문은 알려진 타입을 갖지 못한다.

기본적으로 암시적 any가 되거나 Could not find a declaration file for module './value' 와 같은 오류가 발생한다.

타입스크립트는 단순히 자바스크립트 파일을 타입 검사할 수 있도록 타입스크립트 파일로 변환하는 것 이상을 수행할 수 있다.

자바스크립트 파일도 타입 검사가 가능하다. checkJS 컴파일러 옵션은 두 가지 용도로 사용된다.

• allowJS 옵션이 아직 true 가 아니라면 기본값을 true 로 설정하기
• .js .jsx 파일에서 타입 검사기 활성화하기

checkJS 가 활성화되면 자바스크립트 파일은 잘못된 변수명에 대한 타입 오류가 발생한다.

@ts-check 주석을 사용하면 해당 자바스크립트 파일은 checkJS 옵션이 활성화 된다.

allowJS 와 checkJS 가 활성화되면 타입스크립트 코드는 JSDoc 정의를 인식한다.

점점 더 많은 타입스크립트 프로젝트를 진행하게 되면서 반복적으로 동일한 프로젝트 설정을 작성하는 자신을 발견하게 될 것이다.

비록 타입스크립트는 구성 파일을 자바스크립트로 작성하거나 import 또는 require 사용을 허용하지 않지만

TSConfig 파일이 다른 구성 파일에서 구성 값을 확장하거나 복사하도록 선택하는 메커니즘을 제공한다.

지금까지 보여준 타입스크립트 구성 파일은 프로젝트의 모든 소스 파일을 관리한다고 가정했다.

대규모 프로젝트에서는 프로젝트의 서로 다른 영역에서로 다른 구성 파일을 사용하는 것이 유용할 수 있다.

타입스크립트에서는 여러 개의 프로젝트를 함께 빌드하는 프로젝트 레퍼런스 시스템을 정의할 수 있다.

단일 TSConfig 파일을 사용하는 것보다 조금 더 작업이 많지만 몇 가지 핵심 이점이 있다.

• 특정 코드 영역에 대해 다른 컴파일러 옵션을 지정할 수 있다.
• 타입스크립트는 개별 프로젝트에 대한 빌드 출력을 캐시할 수 있으므로 대규모 프로젝트의 빌드 시간이 훨씬 빨라진다.
• 프로젝트 래퍼런스는 코드의 개별 영역을 구조화하는 데 유용한 의존성 트리를 실행한다.

프로젝트 레퍼런스를 활성화 시키기 위해 프로젝트 설정을 구축하는 방법을 소개한다.

• TSConfig 의 composite 모드는 다중 TSConfig 빌드 모드에 적합한 방식으로 작동하도록 강제한다.
• TSConfig 의 references 는 TSConfig 가 의존하는 복합 TSConfig 를 나타낸다.
• 빌드 모드는 복합 TSConfig 레퍼런스를 사용해 파일 빌드를 조정한다.

composite 구성 옵션을 선택해 파일 시스템 입력과 출력이 제약 조건을 준수함을 나타낸다.

composite 이 true 일 떄는 다음과 같다.

• rootDir 설정이 아직 명시적으로 설정되지 않았다면 기본적으로 TSConfig 파일이 포함된 디렉터리로 설정된다.
• 모든 구현 파일은 포함된 패턴과 일시적으로 파일 배열에 나열되어야 한다.
• declaration 컴파일러 옵션은 반드시 true 이어야 한다.

이러한 변경은 타입스크립트가 프로젝트에 대한 모든 입력 파일과 일치하는 .d.ts 파일을 생성하도록 강제할 때 유용하다.

또한 references 구성 옵션과 함께 사용할 때 유용하다.

references 설정이 있는 복합 타입스크립트 프로젝트에서 생성된 출력에 의존함을 나타낼 수 있다.

참조된 프로젝트에서 모듈을 가져오는 것은 출력 .d.ts 선언 파일에서 가져오는 것으로 타입 시스템에 표시된다.

코드 영역이 프로젝트 레퍼런스를 사용하도록 한번 설정하면 빌드 모드에서 -b 또는 --b CLI 플래그를 통해 tsc 를 사용할 수 있다.

이를 통해 tsc 는 내용과 파일 출력이 마지막으로 생성된 시간을 기준으로 마지막 빌드 이후 변경된 프로젝트만 다시 빌드 한다.

1. TSConfig 의 참조된 프로젝트를 찾는다.
2. 최신 상태인지 감지한다.
3. 오래된 프로젝트를 올바른 순서로 빌드한다.
4. 제공된 TSConfig 또는 TSConfig 의존성이 변경된 경우 빌드한다.

저장소에서 타입스크립트 프로젝트 레퍼런스를 설정하는 편리한 방법은 빈 파일 배열과 저장소의 모든 프로젝트 래퍼런스에 대한 래퍼런스를 사용해 최상위 레벨의 tsconfig.json 을 설정하는 것이다. 최상위 TSConfig 는 타입스크립트가 파일 자체를 빌드하도록 지시하지 않는다.

대신 필요에 따라 참조된 프로젝트를 빌드하도록 타입스크립트에 알리려는 역할만 한다.

{
  "files": [],
  "references": [
    { "path" :  "./packages/core" },
    { "path" :  "./packages/shell"}
  ]
}

빌드 모드는 몇 가지 빌드에 특화된 CLI 옵션을 지원한다.

• --clean: 지정된 프로젝트의 출력을 삭제한다. (--dry 와 함께 사용할 수 있다.)
• --dry: 수행할 작업을 보여주지만 실제로는 아무것도 빌드하지 않습니다.
• --force: 모든 프로젝트가 오래된 것처럼 작동한다.
• -w 또는 --watch: 일반적인 타입스크립트 watch 모드와 동일하다.