[TypeScript] 컴파일 옵션 살펴 보기 (TSConfig Reference)

TSConfig Reference - Docs on every TSConfig option

 

TSConfig 파일이 위치한 디렉토리는 TypeScript 혹은 JavaScript 프로젝트의 루트 디렉토리가 된다. 해당 TSConfig 파일은 tsconfig.json 파일일 수도 있고, jsconfig.json 파일일 수도 있다. 이 둘은 동작 방식이 거의 같으며, 동일한 설정 변수들의 집합을 가진다.

여기서는 TSConfig 파일에서 이용 가능한 각 종류의 프로퍼티들을 다룬다. 주로 사용하는 대표적인 몇 가지 프로퍼티들만 한 번 알아보도록 하자. 자세한 건 여기를 참고하자.

 

1. File Inclusion

1-1. files 프로퍼티

프로그램에 포함하고 싶은 파일들의 목록을 지정한다. 이렇게 지정된 파일 중 하나라도 존재하지 않으면 에러가 발생한다. 참고로 여기에는 파일 확장자까지 정확히 작성해줘야 한다.

{
    "compilerOptions": {},
    "files": [
        "core.ts",
        "sys.ts",
        "types.ts",
        "scanner.ts",
        "parser.ts",
        "utilities.ts",
        "binder.ts",
        "checker.ts",
        "tsc.ts"
    ]
}

이는 파일들을 몇 개 가지고 있지 않아서 glob 패턴으로 많은 파일들을 가리킬 필요가 없는 작은 프로젝트인 경우에 유용하다. glob 패턴이 필요하다면 include 프로퍼티를 사용하면 된다.

 

1-2. include 프로퍼티

프로그램에 포함하고 싶은 파일들의 목록을 지정한다. files 프로퍼티처럼 파일의 상대 경로를 직접 지정할 수도 있고, glob 패턴을 이용하여 많은 파일들을 한 번에 가리키도록 지정할 수도 있다.

{
    "include": ["src/**/*", "tests/**/*"]
}

 

include 프로퍼티와 exclude 프로퍼티의 glob 패턴은 다음과 같은 와일드 카드 문자들을 지원한다.

 

• * : 0개 이상의 문자들과 매칭된다. (디렉토리 구분자는 제외)
• ? : 임의의 한 문자와 매칭된다. (디렉토리 구분자는 제외)
• **/ : 임의의 깊이에 있는 임의의 디렉토리와 매칭된다.

 

만약 glob 패턴이 파일 확장자를 포함하고 있지 않다면, 오직 지원되는 파일 확장자들만 포함된다. 기본적으로는 .ts, .tsx, .d.ts 확장자가 지원되며, allowJS 프로퍼티가 true로 지정되어 있다면 .js, .jsx 확장자까지 지원이 된다.

 

1-3. exclude 프로퍼티

include 프로퍼티에 의해 프로그램에 포함되는 파일들 중 제외시킬 파일들의 목록을 지정한다. 이때 주의해야 할 점은, exclude 프로퍼티에 의해 지정된 파일들도 files 프로퍼티, types 프로퍼티, import 코드, 또는 /// <reference ... /> 디렉티브 등에 의해서 여전히 프로그램의 일부가 될 수 있다는 점이다. 즉 이 프로퍼티는 특정 파일이 프로그램에서 포함되지 않도록 막는 메커니즘이 아니라, 단순히 include 프로퍼티가 지정한 파일들의 목록에만 영향을 미치는 프로퍼티이다.

 

2. Project Options

2-1. noEmit 프로퍼티

컴파일러가 JavaScript 파일 등의 출력 파일들을 만들어 내지 않도록 하는 설정이다. 이는 Babel이나 swc와 같은 또 다른 도구가 TypeScript 파일을 JavaScript 환경에서 실행될 수 있는 파일로 변환하는 작업을 담당할 수 있도록 한다. 이러한 경우에는 TypeScript를 에디터 통합 기능을 제공하기 위한 도구 혹은 소스 코드 타입 체커로만 사용하게 된다.

 

2-2. target 프로퍼티

어떠한 버전의 JavaScript 코드로 컴파일 할지 결정한다. 대부분의 현대 브라우저는 모든 ES6 피쳐들을 지원하기 때문에 ES6도 좋은 선택지이다. 만약 코드가 구식의 환경에서 배포된다면 더 낮은 타겟을 지정해야 하고, 신식의 환경에서만 배포된다는 보장이 있다면 더 높은 타겟으로 지정해도 된다.

즉 이 프로퍼티는 어떠한 JS 피쳐를 하위 버전으로 변환하고 어떠한 JS 피쳐를 그대로 유지할지 결정한다. 예를 들어, target 프로퍼티가 ES5 혹은 그 이하의 버전으로 지정된다면, 컴파일 시 화살표 함수는 일반 함수로 변환이 될 것이다.

target 프로퍼티는 lib 프로퍼티의 기본값도 결정한다. 따라서 target 프로퍼티와 lib 프로퍼티를 권장되는 방식대로 직접 짜맞출 수도 있지만, 편의를 위해 그냥 target 프로퍼티만 지정할 수도 있다.

ESNext라는 특별한 값은 현재 사용하고 있는 버전의 TypeScript가 지원하는 가장 높은 버전을 가리킨다. 이 설정은 주의 깊게 사용되어야 하는데, 왜냐하면 현재 TypeScript의 버전에 따라 ESNext가 가리키는 버전이 달라질 수 있기 때문이다.

 

2-3. module 프로퍼티

프로그램에서 사용할 모듈 시스템을 결정한다. 즉 모듈 내보내기/불러오기 코드가 어떠한 방식의 코드로 컴파일 될지 결정한다. Node.js 프로젝트라면 CommonJS를 선택하는 것이 보통이다. 참고로 module 프로퍼티는 moduleResolution 프로퍼티의 기본값도 결정한다.

 

• CommonJS (target 프로퍼티가 ES3 혹은 ES5로 지정되었을 때의 기본값)
• ES6/ES2015 (target 프로퍼티가 ES6 혹은 그 이상의 버전으로 지정되었을 때의 기본값)
• 나머지 (ES2020, ESNext, AMD, UMD, System, None)

 

2-4. jsx 프로퍼티

JSX 코드를 어떻게 컴파일할지 결정한다. 이는 오직 .tsx 확장자의 컴파일 결과에만 영향을 준다.

 

• react : .js 파일로 컴파일 된다. (JSX 코드는 React.createElement() 함수의 호출로 변환됨)
• react-jsx : .js 파일로 컴파일 된다. (JSX 코드는 _jsx() 함수의 호출로 변환됨)
• react-jsxdev : .js 파일로 컴파일 된다. (JSX 코드는 _jsx() 함수의 호출로 변환됨)
• preserve : .jsx 파일로 컴파일 된다. (JSX 코드가 그대로 유지됨)
• react-native : .js 파일로 컴파일 된다. (JSX 코드가 그대로 유지됨)

// Original TypeScript Sample Code
export const helloWorld = () => <h1>Hello world</h1>;

// Default: "react"
export const helloWorld = () => React.createElement("h1", null, "Hello world");

// React 17 transform: "react-jsx"
import { jsx as _jsx } from "react/jsx-runtime";
export const helloWorld = () => _jsx("h1", { children: "Hello world" }, void 0);

// React 17 dev transform: "react-jsxdev"
import { jsxDEV as _jsxDEV } from "react/jsx-dev-runtime";
const _jsxFileName = "/home/runner/work/TypeScript-Website/TypeScript-Website/packages/typescriptlang-org/index.tsx";
export const helloWorld = () => _jsxDEV("h1", { children: "Hello world" }, void 0, false, { fileName: _jsxFileName, lineNumber: 7, columnNumber: 32 }, this);

// Preserve: "preserve"
export const helloWorld = () => <h1>Hello world</h1>;

// React Native: "react-native"
export const helloWorld = () => <h1>Hello world</h1>;

 

2-5. allowJS 프로퍼티

TypeScript 프로젝트에서 JavaScript 파일도 사용할 수 있도록 하는 설정이다. 이 프로퍼티가 true이면 JavaScript 파일들도 프로젝트에서 import 될 수 있다. 주로 이는 JavaScript 프로젝트를 TypeScript 프로젝트로 바꾸려 할 때 TypeScript 파일들을 점진적으로 추가하기 위한 용도로 사용된다.

// @filename: card.js
export const defaultCardDeck = "Heart";

// @filename: index.ts
import { defaultCardDeck } from "./card";

console.log(defaultCardDeck);  // 이 경우, defaultCardDeck의 타입은 any로 추론된다.

 

2-6. lib 프로퍼티

컴파일 시에 포함시켜야 하는 JavaScript 내장 API들의 타입 정의들에 대한 정보를 지정한다. Math API, document API 등이 그 예시이다. 이 프로퍼티가 지정되어 있지 않다면 target 프로퍼티에 지정된 버전에 따라 필요한 타입 정의들에 대한 정보가 자동으로 지정된다. 예를 들어, target 프로퍼티가 ES6 혹은 그 이상의 버전으로 지정되었는데 lib 프로퍼티가 지정되지 않다면 자동으로 lib 프로퍼티에는 ES2015(= lib.es2015.d.ts 파일) 등의 라이브러리들이 지정되기 때문에 기본적으로 Map의 타입 정보를 전역으로 참조할 수 있게 된다.

 

2-7. isolatedModules 프로퍼티

아직 이해하지 못했음. 이해하고 나면 다시 작성할게요.

 

3. Strict Checks

3-1. strict 프로퍼티

프로그램의 Correctness를 강력하게 보증하기 위한 각종 타입 체킹 동작을 전부 활성화한다. 이 프로퍼티를 true로 지정하면 strict mode family 프로퍼티들을 전부 true로 지정하는 것과 동일하다. 그리고 나서 필요하다면 선택적으로 몇 개의 strict mode family 프로퍼티를 false로 지정할 수 있다.

 

미래에는 TypeScript가 이 프로퍼티가 활성화하는 타입 체킹 동작들의 종류를 더 추가할 것이다. 따라서 TypeScript의 업그레이드가 프로그램의 새로운 타입 에러를 만들어 낼 수도 있음에 주의하자.

 

3-2. strict mode family 프로퍼티들

• alwaysStrict 프로퍼티
• strictNullChecks 프로퍼티
• strictBindCallApply 프로퍼티
• strictFunctionTypes 프로퍼티
• strictPropertyInitialization 프로퍼티
• noImplicitAny 프로퍼티
• noImplicitThis 프로퍼티

 

4. Module Resolution

4-1. baseUrl 프로퍼티

비-상대적 import의 모듈 해석 시에 기준이 되는 경로를 지정한다. 여기에는 루트 디렉토리를 기준으로 한 상대 경로를 지정한다. 예를 들어, 프로젝트의 루트 디렉토리에 존재하는 src 디렉토리를 기준으로 각종 모듈을 불러오고 싶다면 이 프로퍼티를 './src'로 지정하면 된다. 단, 상대적 import의 모듈 해석 과정에는 이 프로퍼티의 지정이 아무런 영향을 주지 않는다.

 

4-2. moduleResolution 프로퍼티

모듈 해석 전략을 결정한다. Node.js 방식대로 모듈 해석을 진행하게 하려면 Node를, 1.6 이전 버전의 TypeScript에서 사용하던 방식대로 모듈 해석을 진행하게 하려면 Classic을 지정한다. 현대 코드에서는 Classic으로 지정할 일이 거의 없을 것이다. 모듈 해석 과정은 여기를 참조하자.

 

4-3. esModuleInterop 프로퍼티

기본적으로(esModuleInterop 프로퍼티가 false로 지정된 경우) TypeScript는 CommonJS, AMD, UMD 모듈도 ES6 모듈인 것처럼 사용할 수 있게 해준다. 이를 위해 다음과 같은 두 가지 방법을 활용한다.

 

1. import * as XXX from "XXX"는 const XXX = require("XXX")로 컴파일 한다.
2. import XXX from "XXX"는 const XXX = require("XXX").default로 컴파일 한다.

그런데 이 두 가지 방법은 각각 다음과 같은 문제를 가지고 있다.

 

1. ES6 모듈 스펙에서는 import * as XXX 코드가 오직 일반 객체 타입의 XXX를 만들어 내야 한다고 말하고 있다. 그러나 TypeScript가 이 코드를 = require("XXX")로 컴파일 하게 한다는 건 XXX가 호출이 가능한(Callable) 함수 타입이 될 수도 있다는 뜻이다. 이는 ES6 모듈 스펙에 어긋난다.
2. CommonJS/AMD/UMD 모듈을 가진 대부분의 라이브러리들은 TypeScript의 구현만큼 엄격하게 규칙들을 준수하지 않는다. 즉, default export가 없는 라이브러리들이 매우 많다.

이때 esModuleInterop 프로퍼티를 true로 지정하면 TypeScript에 의해 트랜스파일 되는 코드에서 위와 같은 두 개의 문제를 모두 해결할 수 있다. JavaScript 코드를 만들어 낼 때 다음과 같은 두 개의 헬퍼 함수를 사용하도록 하는 것이다.

 

1. const XXX = __importStar(require("XXX")) : XXX가 ES6 모듈이면 module.exports 객체를 그대로 반환하고, 아니라면 module.exports의 프로퍼티들을 그대로 가지고 있으며 default 프로퍼티로는 module.exports 자체를 가리키는 또 다른 객체를 만들어 반환한다. 따라서 더 이상 import * as XXX from "XXX"에서의 XXX는 호출 가능한(Callable) 함수 타입이 되지 못한다. 즉 XXX()와 같은 코드를 작성하면 컴파일 에러가 발생하게 된다.
2. const XXX = __importDefault(require("XXX')).default : XXX가 ES6 모듈이면 module.exports 객체를 그대로 반환하고, 아니라면 default 프로퍼티로 module.exports 자체를 가리키는 또 다른 객체를 만들어 반환한다. 따라서 default export가 없는 모듈이라 하더라도 default export가 있는 모듈인 것처럼 default import로 불러와 사용할 수 있게 된다.

 

참고로 XXX가 ES6 모듈이라면, 컴파일 시에 module.exports 객체의 __esModule 프로퍼티가 true로 설정된다. 따라서 XXX를 불러오는 쪽에서는 이 프로퍼티를 검사하면 module.exports 객체가 ES6 모듈로부터 온 것인지, 다른 종류의 모듈에서 온 것인지 쉽게 파악이 가능하다.

런타임 Babel 생태계와의 호환성을 위해서는, 이 프로퍼티를 true로 지정하여 위의 두 헬퍼 함수를 사용하여 컴파일을 진행하게끔 하는 것이 좋다. Babel도 이와 같은 방식으로 컴파일을 하기 때문이다. 그리고 타입 시스템의 호환성을 위해서 --allowSyntheticDefaultImports 프로퍼티도 true로 지정하는 것이 좋은데, 이는 esModuleInterop 프로퍼티를 true로 지정하면 자동으로 true로 지정된다.

▼ Babel에서 ES6 모듈 코드를 CommonJS 모듈 코드로 컴파일 하는 방법 (매우 유사하다)

* 오타 발견 (2021.01.24) : _interopRequireDefault(require("moduleA")).default; 로 수정해야 함.

 

4-4. allowSyntheticDefaultImports 프로퍼티

불러오려는 모듈에 default export가 없을 때도 import as * XXX가 아닌 import XXX를 사용할 수 있도록 하는 설정이다. 이는 TypeScript가 만들어 내는 JavaScript 코드에는 영향을 주지 않고, 단순히 타입 체킹 시에만 사용이 되는 프로퍼티임에 주의하자. esModuleInterop 프로퍼티가 true로 지정되면 기본적으로 이 프로퍼티도 true로 지정이 된다.

위에서 설명하기를, esModuleInterop 프로퍼티를 true로 지정하면 default export가 없는 모듈이라 하더라도 default export가 있는 모듈인 것처럼 default import로 불러와 사용할 수 있도록 컴파일을 한다고 하였다. 따라서 esModuleInterop 프로퍼티가 true이면 allowSyntheticDefaultImports 프로퍼티도 true인 것이 지극히 자연스럽다. 반대로, esModuleInterop 프로퍼티가 false이면 default export가 없는 모듈은 반드시 import as * XXX로 불러와 사용해야 하도록 컴파일을 한다는 뜻이기 때문에 allowSyntheticDefaultImports 프로퍼티도 false인 것이 자연스럽다.

또한 앞서 말했지만 Babel과 같은 트랜스파일러는 default export가 없을 때 이를 자동으로 만들어 냄으로써 default import로 불러와 사용할 수 있게 한다. 따라서 이 프로퍼티를 true로 지정하는 것은 이와 같은 Babel의 동작 방식에 싱크를 맞추어 타입 체킹을 할 수 있게 해주는 것으로 볼 수도 있다. 즉, 이 프로퍼티는 타입 선언 파일에 default export가 없어도 있는 것처럼 인식하게 해주는 것이다.

 

4-5. typeRoots 프로퍼티

기본적으로, 모든 '가시적인' @types 패키지들은 컴파일 목록에 포함이 된다. 여기서 말하는 가시적인 @types 패키지란 임의의 계층에 존재하는 node_modules/@types 디렉토리 내 패키지를 의미한다. 즉, ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/ 등의 경로에 존재하는 패키지들을 의미한다.

그런데 만약 typeRoots 프로퍼티가 특정 경로들로 지정되어 있다면, 오직 그 경로에 존재하는 패키지들만이 컴파일 목록에 포함이 된다. 예를 들어, 다음과 같은 tsconfig.json 파일을 살펴 보자.

{
    "compilerOptions": {
        "typeRoots": ["./typings", "./vendor/types"]
    }
}

 

설정이 이러할 경우 ./typings 경로와 ./vendor/types 경로에 존재하는 패키지들만이 컴파일 목록에 포함이 된다. 즉 node_modules/@types 디렉토리 내에 존재하는 그 밖의 패키지들은 컴파일 목록에 더 이상 포함되지 않는다. 참고로 이 프로퍼티에 지정하는 상대 경로는 tsconfig.json 파일의 경로를 기준으로 한 상대 경로이다.

단, 여기서 컴파일 목록에 포함되는 것은 파일이 아니라 폴더이다. 다시 말해서, index.d.ts 파일 혹은 types 프로퍼티를 가지는 package.json 파일이 존재하는 폴더가 있을 때만 유효하다. typeRoots에 지정된 경로에 .d.ts 확장자의 파일이 있어도 이는 컴파일 목록에 포함되지 않는다는 것이다.

또한 이는 /// <reference types=". . ." /> 디렉티브를 해석할 때의 기준 경로이기도 하다.

 

4-6. types 프로퍼티

기본적으로, 모든 '가시적인' @types 패키지들은 컴파일 목록에 포함이 된다. 여기서 말하는 가시적인 @types 패키지란 임의의 계층에 존재하는 node_modules/@types 디렉토리 내 패키지를 의미한다. 즉, ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/ 등의 경로에 존재하는 패키지들을 의미한다.

그런데 만약 types 프로퍼티가 특정 패키지들로 지정되어 있다면, 오직 그 패키지들만이 컴파일 목록에 포함이 된다. 즉, typeRoots 프로퍼티에 지정된 경로에 존재하는 모든 패키지들이 컴파일 목록에 자동으로 포함되던 효과도 사라진다. 예를 들어, 다음과 같은 tsconfig.json 파일을 살펴 보자.

{
    "compilerOptions": {
        "types": ["node", "jest", "express"]
    }
}

 

설정이 이러할 경우 typeRoots 프로퍼티에 지정된 경로에 존재하는 node 패키지, jets 패키지, 그리고 express 패키지만이 컴파일 목록에 포함이 된다. 즉 typeRoots 프로퍼티에 지정된 경로에 존재하는 그 밖의 패키지들은 컴파일 목록에 더 이상 포함되지 않는다.

 

👉 이 설정의 효과는 무엇일까?

이 설정을 한다고 해서 @types 패키지들이 어플리케이션에 포함되는 방식이 변하진 않는다. 예를 들어, 위의 컴파일 옵션을 그대로 둔 채 다음 코드를 작성했다고 해보자.

import * as moment from "moment";

moment().format("MMMM Do YYYY, h:mm:ss a");

 

types 프로퍼티를 지정해줬음에도 불구하고 moment 모듈에 대한 해석은 아주 잘 이뤄진다. 즉, 다른 파일에서 명시적으로 불러오지 않는 전역 선언 파일을 사용해야 하는 경우에만 의미가 있는 것이다. 다른 파일에서 명시적으로 불러오면 모듈 해석 과정에서 그 타겟 파일이 알아서 컴파일 목록에 포함이 되기 때문이다. 

 

👉 요약 : typeRoots 프로퍼티 vs types 프로퍼티

typeRoots 프로퍼티는 기본적으로 컴파일 목록에 자동으로 포함시킬 패키지들의 경로를 지정한다. 이때 types 프로퍼티를 지정하면 typeRoots 프로퍼티에 지정된 경로에서 types 프로퍼티로 지정된 패키지들만이 컴파일 목록에 포함이 되고 나머지는 포함되지 않게 된다. 즉 typeRoots 프로퍼티가 컴파일 목록에 자동으로 포함시킬 패키지들의 기준 디렉토리를 의미한다면, types 프로퍼티는 그 디렉토리 내에 존재하는 패키지들 중 어떤 패키지들을 컴파일 목록에 포함시킬지를 의미하는 것이라고 볼 수 있다. 만약 types 프로퍼티가 지정되어 있지 않다면 typeRoots 프로퍼티에 지정된 경로의 패키지들은 전부 컴파일 목록에 자동으로 포함이 된다.

 

👉 그래서 컴파일 목록에 포함되는 파일들은 뭔데?

• tsconfig.json 설정에 의해 포함된 파일 (files, include, exclude, typeRoots, types)
• import의 타겟 파일
• /// <referece . . . /> 디렉티브의 타겟 파일

 

5. Linter Checks

5-1. noFallthroughCasesInSwitch 프로퍼티

switch 문에서 Fallthrough Case가 발견되면 에러를 발생시키는 설정이다. 즉 switch 문에서 비어 있지 않은 Case라면 반드시 break 문이나 return 문으로 해당 Case를 종료시키도록 강제한다. 이를 통해 의도치 않은 Fallthrough Case에 의한 버그를 예방할 수 있다.

 

6. Advanced

6-1. forceConsistentCasingInFileNames 프로퍼티

사용할 파일의 이름을 대소문자까지 정확하게 작성하도록 강제하는 설정이다.

TypeScript는 실행이 되는 파일 시스템의 Sensitivity 규칙을 그대로 따른다. 즉 파일 시스템이 대소문자를 구별한다면 TypeScript도 대소문자를 구별하고, 파일 시스템이 대소문자를 구별하지 않는다면 TypeScript도 대소문자를 구별하지 않는다는 것이다. 

이는 대소문자를 구별하는 파일 시스템에서 개발하는 사람과 그렇지 않은 시스템에서 개발하는 사람이 협업을 할 때 문제를 일으킬 수 있다. 어떤 파일이 fileManager.ts 파일을 ./FileManager.ts 형식으로 불러와서 사용했다면, 대소문자를 구별하는 파일 시스템에서는 그 파일이 발견되지 않을 것이지만 대소문자를 구별하지 않는 파일 시스템에서는 그 파일이 발견될 것이기 때문이다. 따라서 이 프로퍼티를 true로 지정하여 그러한 문제의 소지를 애초에 만들지 않도록 하는 것이 권장된다.

 

6-2. resolveJsonModule 프로퍼티

확장자가 .json인 모듈의 import를 허용하는 설정이다. 이러한 패턴은 Node.js 프로젝트에서 매우 흔하다. 이는 해당 정적 JSON의 형태에 근거하여 해당 import에 대한 타입까지 자동으로 만들어 낸다.

// @filename: settings.json
{
    "repo": "TypeScript",
    "dry": false,
    "debug": false
}

// @filename: index.ts
import settings from "./settings.json";

console.log(settings.debug);
console.log(settings.dry === 2);

 

6-3. skipLibCheck 프로퍼티

모든 선언 파일(.d.ts)의 타입 체킹을 스킵하도록 하는 설정이다. 이는 타입 시스템의 정확성을 약간 떨어뜨리는 대가로 컴파일 시간을 획기적으로 줄여주는 방법이다. 보통 서드 파티 라이브러리의 선언 파일들은 이미 타입 체크가 이뤄진 경우가 많고, 심지어 라이브러리의 선언 파일들은 제각기 다른 설정 하에서 타입 체크가 이뤄졌을 것이기 때문에 타입 체크를 다시 시도하는 것은 좋지 않다. 무엇보다 프로젝트의 규모가 크면 라이브러리의 선언 파일들이 매우 방대할 텐데, 그것들을 매번 다시 체크하는 것은 상당한 시간이 소모가 된다. 그래서 이 프로퍼티를 true로 지정하여 선언 파일들의 타입 체크를 생략하도록 하는 것이 권장된다.

 

7. Other References

• TypeScript 컴파일러가 타입 선언을 참조하는 과정 : https://medium.com/naver-fe-platform/타입스크립트-컴파일러가-모듈-타입-선언을-참조하는-과정-5bfc55a88bb6
• module.exports =와 export default의 차이 : https://stackoverflow.com/questions/40294870/module-exports-vs-export-default-in-node-js-and-es6
• import *와 default import가 다름에도 똑같이 동작하는 이유 : https://stackoverflow.com/questions/55285737/import-as-react-from-react-vs-import-react-from-react
• esModuleInterop 프로퍼티에 관한 설명 : https://qastack.kr/programming/56238356/understanding-esmoduleinterop-in-tsconfig-file
• Babel과 CommonJS 모듈 : https://2ality.com/2015/12/babel-commonjs.html