노드JS 타입스크립트(1) 개요 및 설정파일

16 minute read

타입스크립트 개요

타입스크립트를 과정(기본조건)

TypeScript (.ts) 파일을 사용하기 위해서는 다음의 기본 조건들이 필요하다.

Node.js와 TypeScript 설치

TypeScript는 Node.js 환경에서 실행되며, 따라서 Node.js와 TypeScript를 설치해야 한다.
TypeScript 설정 파일(tsconfig.json)

TypeScript 컴파일러는 tsconfig.json이라는 설정 파일을 사용하여 컴파일 옵션을 구성한다. 이 설정 파일은 프로젝트 루트 디렉토리에 위치하며, 필요한 컴파일 옵션들을 지정해야 한다.
TypeScript 파일 작성

TypeScript는 JavaScript의 슈퍼셋이므로, JavaScript와 동일한 문법을 사용할 수 있다. 더불어 TypeScript의 고급 기능들인 정적 타입 검사, 인터페이스, 데코레이터 등을 활용하여 TypeScript 파일을 작성해야 한다.
TypeScript 컴파일

작성한 TypeScript 파일을 JavaScript 파일로 변환하기 위해 TypeScript 컴파일러를 사용해야 한다. tsconfig.json 파일에서 지정한 컴파일 옵션들에 따라 TypeScript 파일을 컴파일하여 JavaScript 파일을 생성할 수 있다.
JavaScript 실행

컴파일된 JavaScript 파일을 실행하여 TypeScript의 고급 기능들이 반영된 코드를 실행할 수 있다. JavaScript 파일은 일반적인 방식으로 실행하면 된다. (예를 들어, Node.js 환경에서는 node 명령어를 사용하여 JavaScript 파일을 실행할 수 있다.)

위의 기본 조건들을 충족시키면 .ts 파일을 사용할 수 있게 된다.

타입스크립트 Node.js 없이 실행하는 법

일반적으로 Node.js가 TypeScript 파일(.ts)을 실행하기 위해 필요한 컴파일 단계를 수행하게 된다. 그러나 아래 방법으로 Node.js 없이 .ts 파일을 실행 할 수있다.

방법1 (Deno)

Deno(https://deno.land/)는 Node.js와 유사한 JavaScript 및 TypeScript 런타임 환경으로, Node.js와 달리 TypeScript 파일을 직접 실행할 수 있다. Deno는 V8 JavaScript 엔진을 사용하며, 특정 버전의 TypeScript를 내장하고 있어 별도의 컴파일 과정 없이 .ts 파일을 실행할 수 있다.
방법2 (ts-node)

ts-node(https://github.com/TypeStrong/ts-node)는 Node.js 환경에서 TypeScript 파일을 실행하기 위한 패키지로, TypeScript 컴파일 단계를 생략하고 직접 .ts 파일을 실행할 수 있다. ts-node를 전역 또는 로컬로 설치한 후에는 명령어를 통해 .ts 파일을 실행할 수 있다.

그러나 이러한 방법들은 Node.js와 비교하여 상대적으로 새로운 기술이라서 주로 쓰진 않는다. 일반적으로 Node.js를 사용하여 .ts 파일을 컴파일하여 실행하는 것이 가장 흔한 방법이다.

STEP1. TypeScript 설치

# 일반적으로 TypeScript를 프로젝트마다 로컬로 설치하는 것이 권장 된다. 
# 이는 프로젝트 내에서 TypeScript의 버전을 관리하고, 
# 프로젝트 별로 다양한 TypeScript 버전을 사용할 수 있는 유연성을 제공하기 위함이다.
npm install typescript 

# package.json
"dependencies": {
    "dotenv": "^16.0.3",
    "express": "^4.18.2",
    "mysql2": "^3.2.0",
    "typescript": "^5.0.4" # 추가되어짐
  }

STEP2. TypeScript 설정 파일(tsconfig.json)

: tsconfig.json 파일을 조정하여 컴파일 옵션을 세밀하게 제어가능하다. TypeScript 프로젝트를 컴파일할 때, 해당 설정에 따라 TypeScript 컴파일러가 동작한다.

tsconfig.json 을 만들지 않은 경우

// 설정 파일이 없을때 디폴트 값을 표현하자면 아래와 같다.
{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": false,
    // 기타 필요한 설정 옵션들
  },
  // 다른 설정 옵션들
}

tsconfig.json 을 작성한 경우(예시)

{
  "compilerOptions": {
    "jsx": "react-jsx",  // JSX 문법 React 컴포넌트 작성가능 
    "target": "es6",     // 컴파일된 JavaScript의 목표 버전 
    "module": "esnext",  // 동적으로 최신 ECMAScript 로딩
    "moduleResolution": "node",  // 컴파일러 모듈해석 방식
    "sourceMap": true,   // 소스맵파일 생성되어 디버깅 유리
 
    "emitDecoratorMetadata": true, // TypeScript 컴파일러는 클래스의 데코레이터에 대한 추가 메타데이터를 생성하여 런타임에서 사용 가능해짐
    "experimentalDecorators": true, // TypeScript에서 데코레이터를 사용할 수 있게된다.
    "removeComments": false, // false: 컴파일된 JavaScript 코드에서 주석을 제거하지 않고 그대로 유지한다.(기본값 true)
    "noImplicitAny": false,  // true: 암묵적으로 "any" 타입으로 추론되는 경우에 컴파일 강제에러 발생

    "supperessImplicitAnyIndexErrors": true, //true: 인덱스로 접근하는 경우에 any 타입으로 추론되는 경우에도 컴파일 에러가 발생하지 않게된다.

    "outDir": "./target/classes/static/app", // 컴파일폴더
    "lib": [             // 라이브러리 추가 폴더
      "dom",
      "es2015", 
      "es2016", 
      "es2017"
    ],
    "allowJs": true, 
    "checkJs": true, 
    "baseUrl": "./src",  // 상대경로

    "importHelpers": true,   // ES, CommonJS 모듈 간 상호개선
    "esModuleInterop": true,  
    "allowSyntheticDefaultImports": true, 
    "skipLibCheck": true, 
    "forceConsistentCasingInFileNames": true, 
    "noFallthroughCasesInSwitch": true, 
    "resolveJsonModule": true, 
    "isolatedModules": true, 
    "noEmit: true, 
    "strict": true
  },
  "include": ["src"],
  "exclude": [
    "node_modules", 
    "./target/classes/static/app"
    //"dist"
    //"build"
  ]
}

옵션 설명

`"jsx": "react-jsx"`

"jsx": "react-jsx"

JSX 문법 React 컴포넌트 작성가능

`"target": "es6"`

"target": "es6"

컴파일된 JavaScript의 목표 버전을 지정. 일반적으로 “es5”나 “es6”를 사용.

`"module": "commonjs"`

"module": "commonjs"

모듈 시스템을 지정. “commonjs”는 Node.js 환경에서 일반적으로 사용되는 CommonJS 스타일의 모듈 시스템을 지정한다. 물론 다른 모듈 시스템 지정도 가능하다. “esnext” 인 경우는 동적으로 최신 ECMAScript 를 로딩한다.
```
  // "commonjs" 으로 모듈 시스템을 지정

  // 컴파일 명령을 실행하면 example.ts 파일이 example.js 파일로 컴파일되며, 
  // 해당 파일은 Node.js에서 commonjs 모듈시스템 옵션 기반으로 require 함수를 사용하여 로드하고 내보낸 함수를 따위를 사용할 수 있게 된다.

  // 아래는 CommonJS 스타일의 모듈 내보내기 방식을 따른다. (레거시한 방법)
  // require() 함수 사용: require() 함수를 사용하여 moment 모듈을 불러온 후, moment 변수에 할당하여 모듈을 사용. 이 방식은 Node.js 환경이나 이전 버전의 JavaScript에서 주로 사용.

  // module.exports 사용: export 구문 대신 module.exports 객체를 사용하여 모듈을 내보낼 수 있습니다. 

  // 모듈 가져오기
  const fs = require('fs');
  const path = require('path');

  // 모듈 내보내기
  function foo() {
  console.log('This is a function from a CommonJS module.');
  }
  module.exports = foo;
```
commonjs 옵션을 false로 설정하는 경우는 일반적으로 Node.js 환경이 아닌 브라우저 환경에서 TypeScript 코드를 실행하고자 할 때 사용된다. 브라우저 환경에서는 CommonJS 스타일의 모듈 시스템이 아닌 ES 모듈(ESM) 시스템이 널리 사용되기 때문이다. 예를 들어, 브라우저에서 사용되는 모던 프론트엔드 프레임워크 또는 라이브러리인 React, Vue, Angular 등은 ES 모듈 형태로 제공되며, 이러한 프로젝트에서는 commonjs 옵션을 false로 설정하여 컴파일된 코드가 ES 모듈 형태로 내보내지도록 할 수 있다.

다양한 예시는 다음과 같습니다.

“module”: “es6”: 이 옵션을 설정하면, TypeScript 컴파일러가 ES6 스타일의 모듈 시스템을 사용하여 코드를 컴파일합니다. 컴파일된 JavaScript 코드는 import와 export 키워드를 사용하여 모듈을 정의하고 불러올 수 있습니다. 이 모듈 시스템은 대부분의 최신 브라우저와 Node.js에서 기본적으로 지원되어 있습니다.

“module”: “es2015”: 이 옵션은 “es6”과 동일한 기능을 제공하며, TypeScript 1.5 버전 이전에 사용되던 구식의 옵션 이름입니다. 현재는 “es6”을 사용하는 것이 권장됩니다.

“module”: “esnext”: 이 옵션을 설정하면, TypeScript 컴파일러가 ECMAScript의 최신 버전을 사용하여 코드를 컴파일합니다. 최신 JavaScript 기능인 async/await, generators, for…of 등을 사용할 수 있습니다. 그러나 이 모듈 시스템은 모든 브라우저와 환경에서 지원되지 않을 수 있으므로, 이 옵션을 사용할 때에는 주의가 필요합니다.

일반적으로 “module”: “es6”이나 “module”: “es2015”를 사용하는 것이 가장 일반적이고 안전한 선택입니다. “module”: “esnext”는 최신 JavaScript 기능을 사용하고자 할 때에만 사용되어야 하며, 지원하는 환경에 대해 충분한 테스트와 확인이 필요합니
```
  // "es6" 으로 모듈 시스템을 지정
  {
  "compilerOptions": {
      "module": "es6", // 또는 "es2015", "esnext" 등 ES 모듈로 설정
  }
  }
```

`"moduleResolution": "node"`

"moduleResolution": "node"

컴파일러 모듈해석 방식. 2가지가 존재한다.
- “node”: 이 값은 Node.js의 모듈 해석 알고리즘을 사용하도록 TypeScript 컴파일러에 지시한다. 이 알고리즘은 Node.js의 모듈 해석 규칙을 따르며, “node_modules” 폴더를 기준으로 모듈을 찾는다. 이는 디폴트한 TypeScript 컴파일러의 설정 값이다.
- “classic”: 이 값은 이전 버전의 TypeScript 컴파일러에서 사용되던 모듈 해석 알고리즘인 “classic” 알고리즘을 사용하도록 지시한다. 이 알고리즘은 상대적인 파일 경로를 기준으로 모듈을 찾습니다.

`"sourceMap": true`

"sourceMap": true

sourceMap 옵션을 사용하면 소스맵 파일이 함께 생성되어, 디버깅 시에 원본 TypeScript 소스코드와 연결하여 디버깅이 편해진다. 일반적으로 .js.map 확장자를 가지며, 컴파일된 JavaScript 파일과 동일한 디렉토리에 생성된다.

`"emitDecoratorMetadata": true`

"emitDecoratorMetadata": true

TypeScript 컴파일러는 클래스의 데코레이터에 대한 추가 메타데이터를 생성하여 런타임에서 사용 가능해짐

`"experimentalDecorators": true`

"experimentalDecorators": true

TypeScript에서 데코레이터를 사용할 수 있게된다.

`"removeComments": false`

"removeComments": false

false: 컴파일된 JavaScript 코드에서 주석을 제거하지 않고 그대로 유지한다.(기본값 true)

`"noImplicitAny": false`

"noImplicitAny": false

true: 암묵적으로 “any” 타입으로 추론되는 경우에 컴파일 강제에러 발생

`"suppressImplicitAnyIndexErrors": true`

"suppressImplicitAnyIndexErrors": true: 옵션은 TypeScript 컴파일러에서 암묵적으로 any 타입으로 추론되는 인덱스 접근의 에러 메시지를 숨기는 옵션. 이 옵션을 사용하면, 인덱스로 접근하는 경우에 any 타입으로 추론되는 경우에도 컴파일 에러가 발생하지 않는다.

  // "suppressImplicitAnyIndexErrors" 옵션이 TRUE 
  // obj는 any 타입으로 선언되어 있기 때문에 obj.prop이나 obj["prop"]와 같은 인덱스 접근이 any 타입으로 추론. 그러나 "suppressImplicitAnyIndexErrors" 옵션이 true로 설정되어 있으면, 컴파일 에러가 발생하지 않는다.
  const obj: any = { prop: "value" };
  const propValue = obj.prop; // 컴파일 에러 발생하지 않음
  const propValue2 = obj["prop"]; // 컴파일 에러 발생하지 않음

 
  // "suppressImplicitAnyIndexErrors" 옵션이 FALSE 
  // any 타입으로 추론되는 인덱스 접근은 컴파일 에러가 발생한다.
  const obj: any = { prop: "value" };

  const propValue = obj.prop; // 컴파일 에러 발생: Property 'prop' does not exist on type 'any'

  const propValue2 = obj["prop"]; // 컴파일 에러 발생: Element implicitly has an 'any' type because index expression is not of type 'number' or 'symbol'
    

`"outDir": ./dist`

"outDir": ./dist"

TypeScript 컴파일된 JavaScript 파일을 지정된 디렉토리에 출력.

`"lib": [dir1,dir2,file1]`

"lib": [dir1,dir2,file1]

생략

`"allowJs": true`

"allowJs": true

“allowJs” 옵션은 TypeScript 컴파일러에서 JavaScript 파일을 허용할지 여부를 지정하는 옵션입니다. 기본적으로 TypeScript는 .ts 확장자를 가진 TypeScript 파일만 컴파일하도록 설정되어 있습니다. 하지만 “allowJs” 옵션을 사용하면 TypeScript 컴파일러가 .js 확장자를 가진 JavaScript 파일도 컴파일할 수 있습니다.

“allowJs” 옵션을 true로 설정하면, TypeScript 컴파일러는 .ts 확장자뿐만 아니라 .js 확장자를 가진 JavaScript 파일도 컴파일합니다. 이를 통해 TypeScript 프로젝트에 JavaScript 파일을 혼용하여 사용할 수 있게 됩니다.

“allowJs” 옵션은 tsconfig.json 파일에서 다음과 같이 설정할 수 있습니다:

`"checkJs": true`

"checkJs": true

“checkJs” 옵션은 TypeScript 컴파일러에서 JavaScript 파일의 타입 체크를 수행할지 여부를 지정하는 옵션입니다. 기본적으로 TypeScript는 .ts 확장자를 가진 TypeScript 파일만 타입 체크하도록 설정되어 있다. 하지만 “checkJs” 옵션을 사용하면 TypeScript 컴파일러가 .js 확장자를 가진 JavaScript 파일도 타입 체크할 수 있다. 이를 통해 TypeScript 프로젝트에 JavaScript 파일을 혼용하여 사용할 수 있게 된다. 그런데 “checkJs” 옵션을 사용하는 경우에는 주의가 필요하다. TypeScript는 .js 파일도 타입 체크하게 되므로, JavaScript 파일 내에 TypeScript와 호환되지 않는 문법이나 타입이 있는 경우 타입 체크 에러가 발생할 수 있다. 따라서, “checkJs” 옵션을 사용할 때에는 JavaScript 파일 내의 코드가 TypeScript와 호환되는지 확인하는 것이 중요하다. 이 옵션은 주로 JavaScript 파일을 TypeScript 프로젝트에 추가할 때, 타입 체크를 활성화하고 싶은 경우에 사용된다.

`"baseUrl": true`

"baseUrl": true

생략

`"importHelpers": true`

"importHelpers": true

이 옵션은 주로 ECMAScript 5 이하의 타겟 버전으로 컴파일할 때, 코드 크기와 실행 성능을 개선하고자 할 때 사용된다.

true 옵션은 TypeScript 컴파일러가 Babel 헬퍼 함수를 사용하여 트랜스파일된 코드를 최적화하는 옵션입니다.

TypeScript에서 ECMAScript 5 이하의 타겟 버전으로 컴파일하면, 몇 가지 도우미 함수(헬퍼 함수)가 필요합니다. 예를 들어, ES6의 클래스를 ES5로 트랜스파일할 때, 클래스 상속 및 메소드 오버라이딩과 같은 ES6 기능을 ES5로 변환하는데 일부 도우미 함수가 필요합니다. 이 도우미 함수들은 중복적으로 생성되는 경우가 많기 때문에, “importHelpers”: true 옵션을 사용하여 이를 최적화할 수 있습니다.

“importHelpers”: true 옵션을 설정하면, TypeScript 컴파일러는 도우미 함수들을 중복 생성하는 대신, “@babel/helpers”와 같은 외부 Babel 헬퍼 함수 라이브러리를 사용하여 코드를 최적화합니다. 이를 통해, 트랜스파일된 코드의 크기를 줄이고 실행 성능을 향상시킬 수 있습니다.

`"esModuleInterop": true`

"esModuleInterop": true

“esModuleInterop”: true 옵션은 TypeScript에서 CommonJS 모듈 형식으로 작성된 외부 라이브러리를 더 쉽게 사용할 수 있도록 도와주는 옵션입니다.

일반적으로, CommonJS 모듈 형식은 require() 함수를 사용하여 모듈을 가져오고, 이를 사용하기 위해서는 객체의 default 프로퍼티를 참조해야 하는 경우가 많습니다. 하지만, ES 모듈 형식은 import 문을 사용하고, default 프로퍼티를 참조할 필요가 없이 바로 모듈을 사용할 수 있습니다. “esModuleInterop”: true 옵션은 이러한 차이를 극복하기 위해, CommonJS 모듈 형식의 라이브러리를 ES 모듈 형식처럼 사용할 수 있게 해줍니다.

“esModuleInterop”: true 옵션을 설정하면, TypeScript 컴파일러는 import 문을 사용하여 CommonJS 모듈을 가져올 수 있으며, default 프로퍼티를 참조할 필요가 없이 바로 모듈을 사용할 수 있습니다. 이를 통해, 외부 라이브러리를 더 간편하게 사용할 수 있고, 코드의 가독성을 향상시킬 수 있습니다.
```
  // 외부 라이브러리인 moment.js를 CommonJS 모듈 형식으로 사용하는 경우

  // CommonJS 모듈 형식으로 moment.js를 가져옴
  const moment = require('moment');

  // moment.js의 함수를 사용
  const now = moment();

  // "esModuleInterop": true 옵션을 사용한 경우

  // ES 모듈 형식으로 moment.js를 가져옴
  import * as moment from 'moment';

  // moment.js의 함수를 사용
  const now = moment();
```
위 예시에서, “esModuleInterop”: true 옵션을 설정한 경우에는 import * as moment from ‘moment’;와 같이 ES 모듈 형식으로 외부 라이브러리를 가져와서 사용할 수 있습니다. 이를 통해, default 프로퍼티를 참조할 필요 없이 모듈을 사용할 수 있습니다.

** 추가자료) esModuleInterop **
ES 모듈과 CommonJS 모듈 간의 상호 운용성을 활성화 개선한다.(대부분의 경우 true 이다.) import 구문으로 CommonJS 모듈을 가져올 수 있고, export default 구문으로 ES 모듈을 내보낼 수 있게된다.
```
  /* esModuleInterop 옵션이 true인 경우 */

  // 모듈을 가져올 때 import from 구문 사용 가능
  import * as fs from 'fs';

  // CommonJS 모듈을 가져올 때도 import 구문 사용 가능
  import * as path from 'path';

  // ES 모듈로 내보낼 때 export default 사용 가능
  export default function foo() {
  console.log('This is a default export from an ES module.');
  }

  // CommonJS 모듈로 내보낼 때도 export = 사용 가능
  export = function bar() {
  console.log('This is a CommonJS export from a CommonJS module.');
  };
```
```
  /* esModuleInterop 옵션이 false인 경우 */

  // 모듈을 가져올 때는 require()를 사용한 형태의 코드 사용
  import fs = require('fs');

  // CommonJS 모듈을 가져올 때는 require() 함수 사용
  const path = require('path');

  // ES 모듈로 내보낼 때는 export default 사용
  export default function foo() {
  console.log('This is a default export from an ES module.');
  }

  // CommonJS 모듈로 내보낼 때는 module.exports 사용
  module.exports = function bar() {
  console.log('This is a CommonJS export from a CommonJS module.');
  };
```
잠깐!)
CommonJS 모듈로 내보낼 때는 module.exports를 사용하고, ES 모듈로 내보낼 때는 export default를 사용한다.
참고로 ES모듈 방식은 보편적으로 사용되는 현대적인 JavaScript 개발 방식이다.

`"allowSyntheticDefaultImports": true`

"allowSyntheticDefaultImports": true

allowSyntheticDefaultImports 옵션은 TypeScript에서 모듈을 가져올 때, CommonJS 모듈 형식의 모듈에서 default 익스포트를 사용하기 위한 옵션입니다.

일반적으로 CommonJS 모듈에서 default 익스포트를 사용하려면 import 문을 다음과 같이 작성해야 합니다.
```
  // CommonJS 모듈에서 default 익스포트를 사용하는 경우
  // 모듈 파일 (module.js)
  module.exports = {
      default: 'Hello, world!'
  };

  // 다른 모듈에서 사용
  const myDefaultExport = require('./module.js').default;
  console.log(myDefaultExport); // 'Hello, world!'
```
이를 allowSyntheticDefaultImports 옵션을 사용하면 아래와 같이 더 간단하게 작성할 수 있습니다.
```
  // allowSyntheticDefaultImports 옵션을 사용한 경우
  // CommonJS 스타일 모듈
  // module.js
  module.exports = {
      default: 'Hello, world!'
  };

  // ES6 스타일 import 구문 (allowSyntheticDefaultImports 옵션이 true인 경우)
  import myDefaultExport from './module.js';
  console.log(myDefaultExport); // 'Hello, world!'
    
```
TypeScript 컴파일러가 import 구문에 대한 경고를 제거할 수 있습니다. 이는 CommonJS 스타일의 모듈에서 export default를 사용한 경우에 발생하는 “모듈은 기본적으로 지원되지 않습니다”와 같은 경고를 없애줍니다. 따라서, allowSyntheticDefaultImports 옵션을 true로 설정하면, CommonJS 스타일의 모듈에서 ES6 스타일의 export default 문법을 사용한 모듈을 더 간편하게 불러올 수 있고, TypeScript 컴파일러의 경고를 제거할 수 있습니다.

즉, allowSyntheticDefaultImports 옵션을 활성화하면 CommonJS 모듈에서 default 익스포트를 사용하는 경우에도 일반적인 ES6 스타일의 import 문을 사용할 수 있습니다. 이를 통해 모듈을 더 간단하게 가져와 사용할 수 있게 됩니다. 다만, 이 옵션을 사용할 때에는 해당 모듈이 실제로 default 익스포트를 제공하는지 확인하는 것이 중요합니다.

`"skipLibCheck": true`

"skipLibCheck": true

skipLibCheck 옵션은 TypeScript에서 라이브러리 파일의 유효성 검사를 건너뛸 때 사용하는 옵션입니다. 일반적으로 TypeScript 컴파일러는 .d.ts 확장자를 가진 라이브러리 정의 파일을 사용하여 라이브러리의 타입 정보를 확인하고 검사합니다. 하지만 skipLibCheck 옵션을 사용하면 이런 라이브러리 파일의 유효성 검사를 건너뛰고 컴파일을 수행할 수 있습니다.

skipLibCheck 옵션을 사용하는 경우, TypeScript 컴파일러는 라이브러리 파일의 타입 정보를 확인하지 않고, 라이브러리 파일에 정의된 타입을 그대로 사용합니다. 이는 컴파일 시간을 단축시키고, 라이브러리 파일이 올바르게 작성되지 않았거나 누락된 타입 정보가 있는 경우에도 컴파일을 허용할 수 있습니다.

skipLibCheck 옵션은 주로 대규모 라이브러리를 사용하는 프로젝트에서 빠른 컴파일 속도를 추구하거나, 타입 정보가 불완전하거나 잘못된 경우에 일시적으로 사용될 수 있습니다. 그러나 이 옵션을 사용할 때에는 라이브러리 파일의 타입 정보가 정확하고 완전한지 확인하는 것이 중요하며, 사용 시 주의가 필요합니다.

`"forceConsistentCasingInFileNames": true`

"forceConsistentCasingInFileNames": true

forceConsistentCasingInFileNames 옵션은 파일 이름의 대소문자 일관성을 강제하는 TypeScript의 컴파일 옵션입니다.

이 옵션을 사용하면, 파일 이름의 대소문자를 일관성 있게 작성하지 않은 경우에 컴파일 에러를 발생시킵니다. 예를 들어, 파일 이름이 myFile.ts인데 코드 내에서 import 또는 require를 사용할 때 MyFile 또는 myfile와 같이 대소문자를 다르게 작성한 경우에 컴파일 에러가 발생합니다.

이 옵션은 파일 이름의 대소문자를 일관성 있게 작성하여 파일 시스템의 대소문자 구분 여부에 상관없이 일관된 파일 이름을 사용할 수 있도록 도와줍니다. 일관성 있는 파일 이름은 다양한 운영 체제와 파일 시스템에서 프로젝트를 공유하고 협업할 때 유용하며, 파일 이름 관련 오류를 방지할 수 있습니다.

forceConsistentCasingInFileNames 옵션은 주로 크로스 플랫폼 프로젝트에서 파일 이름의 대소문자 일관성을 유지하고자 할 때 사용됩니다. 그러나 이 옵션을 사용할 때에는 파일 시스템의 대소문자 구분 여부와 프로젝트 내의 파일 이름을 일치시키는 것이 중요하며, 주의가 필요합니다.

`"noFallthroughCasesInSwitch": true`

"noFallthroughCasesInSwitch": true

noFallthroughCasesInSwitch 옵션은 TypeScript의 컴파일 옵션 중 하나로, switch 문에서 case 블록 사이에 break 문이 누락된 경우 컴파일 에러를 발생시키는 옵션입니다.

일반적으로 switch 문에서 case 블록이 연속적으로 나열되어 있을 때, 각 case 블록은 break 문이나 return 문 등으로 명시적으로 종료되어야 합니다. 그렇지 않으면 이후의 case 블록들도 실행되게 되는 “fall-through” 현상이 발생할 수 있습니다. 이는 버그의 원인이 될 수 있으므로 주의가 필요합니다.

noFallthroughCasesInSwitch 옵션을 사용하면, switch 문에서 fall-through가 발생하는 경우 컴파일 에러를 발생시켜 이를 방지할 수 있습니다.
```
  function foo(color: string) {
    switch (color) {
      case 'red':
        console.log('Color is red');
        // break; // 주석 처리된 경우, fall-through 발생
      case 'blue':
        console.log('Color is blue');
        break;
      default:
        console.log('Color is unknown');
        break;
    }
  }
    
```

`"resolveJsonModule": true`

"resolveJsonModule": true

resolveJsonModule 옵션은 TypeScript의 컴파일 옵션 중 하나로, JSON 파일을 모듈로 인식하고, 해당 모듈을 임포트하여 사용할 수 있게 해주는 옵션입니다.

일반적으로 TypeScript에서는 JavaScript 파일과 TypeScript 파일을 모듈로 사용할 수 있지만, JSON 파일은 기본적으로 모듈로 사용할 수 없습니다. 그러나 resolveJsonModule 옵션을 사용하면 TypeScript에서 JSON 파일을 모듈로 취급하여 임포트하여 사용할 수 있습니다.

예를 들어, 아래의 예시 코드에서 tsconfig.json 파일에 resolveJsonModule 옵션을 true로 설정한 경우, JSON 파일을 모듈로 인식하여 임포트할 수 있습니다.
```
  // config.json
  {
    "apiEndpoint": "https://api.example.com",
    "apiKey": "abcdefgh"
  }

  // JSON 파일을 모듈로 인식하여 임포트 가능해짐 
```
```
  // app.ts
  import config from './config.json';

  console.log(config.apiEndpoint); // "https://api.example.com"
  console.log(config.apiKey); // "abcdefgh"
```

`"isolatedModules": true`

"isolatedModules": true

isolatedModules 옵션은 TypeScript의 컴파일 옵션 중 하나로, 개별적인 모듈들을 각각의 파일로 컴파일하는 옵션입니다.

일반적으로 TypeScript에서는 여러 개의 파일로 나뉜 모듈들을 함께 컴파일하여 하나의 JavaScript 파일로 생성합니다. 이는 일반적인 개발 환경에서는 유용하게 동작하지만, 특정 상황에서는 문제가 될 수 있습니다. 예를 들어, 특정 모듈만 변경하여 다시 컴파일하고자 할 때, 전체 프로젝트를 다시 컴파일해야 하는 등의 번거로움이 발생할 수 있습니다.

isolatedModules 옵션을 사용하면, 개별적인 모듈들을 각각의 파일로 컴파일하여 독립적인 JavaScript 파일들을 생성합니다. 이를 통해 개별 모듈의 수정 시에 해당 모듈만 다시 컴파일하여 빠르게 테스트 및 개발을 할 수 있게 됩니다.

예를 들어, 아래의 예시 코드에서 tsconfig.json 파일에 isolatedModules 옵션을 true로 설정한 경우, 개별 모듈들을 각각의 파일로 컴파일합니다.
```
  // moduleA.ts
  export const foo = "Module A";

  // moduleB.ts
  export const bar = "Module B";

  // main.ts
  import { foo } from "./moduleA";
  import { bar } from "./moduleB";

  console.log(foo);
  console.log(bar);
```
위의 예시 코드에서 moduleA.ts와 moduleB.ts는 각각의 독립적인 모듈로 구성되어 있습니다. 이를 isolatedModules 옵션을 true로 설정하여 개별 파일로 컴파일하려면, 다음과 같이 tsc 커맨드를 실행하면 됩니다.
```
  tsc --isolatedModules moduleA.ts moduleB.ts main.ts
```
위 커맨드를 실행하면, 각각의 모듈(moduleA.ts, moduleB.ts)이 개별적으로 컴파일되어 각각의 JavaScript 파일(moduleA.js, moduleB.js)이 생성됩니다. 이후 main.ts 파일에서는 컴파일된 모듈들을 import하여 사용할 수 있습니다. 이를 통해 개별 모듈의 수정 시에 해당 모듈만 다시 컴파일하여 빠르게 개발 및 테스트를 진행할 수 있습니다.

또 다른 예시는 다음과 같다.
```
  // moduleA.ts
  export const moduleAValue = "Hello from module A!";

  // moduleB.ts
  import { moduleAValue } from "./moduleA";
  console.log(moduleAValue);

  // tsconfig.json (isolatedModules: true)
  {
  "compilerOptions": {
      "module": "es6",
      "isolatedModules": true
  }
  }

  // 실행 결과 (isolatedModules: true)
  // Error: Cannot use import statement outside a module

  // tsconfig.json (isolatedModules: false)
  {
  "compilerOptions": {
      "module": "es6",
      "isolatedModules": false
  }
  }

  // 실행 결과 (isolatedModules: false)
  // Hello from module A!
```
위 예시에서 moduleA.ts와 moduleB.ts는 두 개의 모듈로 구성되어 있습니다. moduleB.ts에서 moduleA.ts를 import 하고, moduleAValue 값을 출력하려고 시도하고 있습니다.

tsconfig.json의 isolatedModules 옵션을 true로 설정한 경우, 개별 모듈을 독립적으로 컴파일하려고 시도하면 에러가 발생합니다. 반면에, isolatedModules 옵션을 false로 설정한 경우, 모든 모듈을 한 번에 컴파일하여 JavaScript 파일로 생성되며, 모듈 간의 의존성이 해결되어 moduleAValue 값을 정상적으로 출력할 수 있습니다.

`"noEmit: true`

"noEmit: true

noEmit 옵션을 true로 설정하면, TypeScript 컴파일 시에 JavaScript 파일을 생성하지 않습니다. 즉, .ts 파일을 컴파일한 결과로 .js 파일이 생성되지 않습니다.

이 옵션은 주로 TypeScript를 사용하여 타입 체크만 수행하고 JavaScript 파일을 생성하지 않고 싶은 경우에 사용될 수 있습니다. 예를 들어, TypeScript를 사용하여 코드의 타입을 검증하고, 컴파일된 JavaScript 파일은 다른 도구나 환경에서 따로 처리하고자 할 때 유용할 수 있습니다.

`"strict": true`

"strict": true: 엄격한 타입 체크를 활성화. (강력한 타입 검사 기능을 사용하려면 true)

  # "strict" 옵션 TRUE 인 경우
  "strictNullChecks": null과 undefined를 다른 타입과 구분하여 사용할 수 있도록 합니다.
  "strictFunctionTypes": 함수의 매개변수와 반환값의 타입을 엄격하게 체크합니다.
  "strictPropertyInitialization": 클래스의 프로퍼티가 초기화되지 않았을 경우 경고 또는 에러를 발생시킵니다.
  "strictBindCallApply": 함수의 bind, call, apply 메서드의 사용을 제한합니다.
  "strictNullChecks": null과 undefined의 사용을 엄격하게 제한합니다.
  "noImplicitAny": 암묵적으로 any 타입을 사용하는 것을 금지합니다.

`include`

include: include 옵션이 지정되지 않은 경우, 기본적으로 프로젝트 디렉토리 내의 모든 .ts 및 .tsx 파일이 컴파일 대상으로 간주된다.

  {
  // 파일 확장자를 포함한 파일 경로: src/app.ts, src/utils/*.ts
  // 디렉토리 경로: src, src/**/*.ts
  "include": [
    "./src/**/*.ts"
  ],
  }
    

`exclude`

exclude

컴파일 대상에서 제외할 파일 또는 디렉토리를 지정하는 옵션. exclude 옵션이 지정되지 않은 경우, 기본적으로 node_modules, bower_components, jspm_packages와 같은 특정 디렉토리들이 자동으로 제외된다.
```
  {
  // 파일 확장자를 포함한 파일 경로: src/app.spec.ts, src/utils/**/*.spec.ts
  // 디렉토리 경로: node_modules, build(또는 dist)
  "exclude": [
  "node_modules",
  "build",
  "dist", 
  "test/**/*.ts"
  ]
  }
```
build, dist 디렉터리에 대해서
build(또는 dist) 디렉토리는 TypeScript 프로젝트에서 컴파일된 JavaScript 파일들이 생성되는 관례적인 디렉토리를 의미한다. 일반적으로 TypeScript 소스 코드가 컴파일되어 생성된 JavaScript 파일들을 저장하는 곳으로 사용된다. 예를 들어, TypeScript 소스 코드를 컴파일하여 JavaScript 모듈들을 생성하고, 이를 브라우저에서 실행하기 위해 build(또는 dist) 디렉토리에 저장하는 경우가 많다.

build(또는 dist) 주로 프로덕션 빌드 또는 배포용으로 사용되며 일반적으로 exclude 옵션에 build(또는 dist) 디렉토리를 명시하여 컴파일 대상에서 제외시킴으로써, 컴파일된 JavaScript 파일들이 다시 TypeScript 컴파일 과정에 참여하지 않도록 한다. 이는 중복 컴파일이나 불필요한 작업을 피하고, 성능과 빌드 속도를 향상시킬 수 있습니다.

타입스크립트 개요

타입스크립트를 과정(기본조건)

타입스크립트 Node.js 없이 실행하는 법

STEP1. TypeScript 설치

STEP2. TypeScript 설정 파일(tsconfig.json)

tsconfig.json 을 만들지 않은 경우

tsconfig.json 을 작성한 경우(예시)

옵션 설명

"jsx": "react-jsx"

"target": "es6"

"module": "commonjs"

"moduleResolution": "node"

"sourceMap": true

"emitDecoratorMetadata": true

"experimentalDecorators": true

"removeComments": false

"noImplicitAny": false

"suppressImplicitAnyIndexErrors": true

"outDir": ./dist

"lib": [dir1,dir2,file1]

"allowJs": true

"checkJs": true

"baseUrl": true

"importHelpers": true

"esModuleInterop": true

"allowSyntheticDefaultImports": true

"skipLibCheck": true

"forceConsistentCasingInFileNames": true

"noFallthroughCasesInSwitch": true

"resolveJsonModule": true

"isolatedModules": true

"noEmit: true

"strict": true

include

exclude

STEP3. TypeScript 파일 작성(다음포스팅)

STEP4. TypeScript 컴파일(다음포스팅)

STEP5. JavaScript 실행(다음포스팅)

Share on

Leave a comment

You may also enjoy

메타관리

스프링 Mybatis와 JPA

스프링 에러처리(2) 디테일 커스텀처리