⚙️ tsconfig

tsconfig를 설정하는 이유는?

• vscode가 typescript를 제어하는 방법을 제어
  • vscode의 경우 프로젝트 root에 반드시 tsconfig를 넣어주어야 한다. 별도의 방법을 제공하지 않는다.
• tsc가 typescript를 컴파일하는 방법을 제어

내가 써봤던 설정은?

종류

• 파일 관련 설정
• 컴파일 관련 설정
  • JS 문법 관련
  • 모듈 시스템 관련
  • 선언 파일 관련 (d.ts)
  • 외부 라이브러리 관련

📂 파일 관련 설정

• files, include, exclude : 원하는 파일을 선택하고, 제외하는 설정
• 경로는 tsconfig.json의 위치에서 상대경로로 작성하면 된다.

files

• 원하는 파일만 tsc가 처리하도록 할 수 있다.
• 즉, 터미널에서 tsc target.ts 하는 것과 같다.

include

• 프로그램에 포함할 파일 이름 또는 패턴의 배열을 지정한다.
• pattern 형태로 원하는 파일 목록을 지정할 수 있다.

exclude

• include에 지정한 파일이나 패턴을 제외시킬 수 있다.
• 지정하지 않으면 ["node_modules", "bower_components", "jspm_packages"] 와 outDir에 지정한 경로가 기본값

📂 컴파일 관련 설정 (compilerOptions)

• 컴파일 관련 설정
  • JS 문법 관련
  • 모듈 시스템 관련
  • 선언 파일 관련 (d.ts)
  • 외부 라이브러리 관련

target (:js 문법 관련)

• 컴파일된 결과물의 문법 형태를 정할 수 있다.
• 기본값은 ES3
• 만약 ES5를 선택하면 화살표함수가 함수 선언문(function) 형태로 바뀔 것이다. (화살표 함수 이전)
• esnext : ES6 이후 버전들을 통틀어 esnext라고 한다.
  

module (:모듈 시스템 관련)

• 컴파일된 결과물이 사용할 module 방식
• 만약 commonjs를 선택한다면 require 사용, es6~는 import 사용

esModuleInterop (:모듈 시스템 관련)

• module 시스템이 혼재되어 있을 때 esModuleInterop: true면 호환해준다.
• 만약 module1이 commonjs방식으로 작성되어 export 되어 있다면 esmodule 방식으로 module1을 import할 때 호환이 되지 않는다. 이를 해결해주는 옵션
  

isolatedModules (:모듈 시스템 관련)

• 파일을 모듈로 만들 것을 강제한다.
• isolatedModules: true로 설정하면 모듈로 코드를 작성하지 않은 경우 에러를 출력한다.
• 만약 파일에서 import / export를 사용하지 않은 경우 그 파일은 전역 공간으로 정의된다.
  

moduleResolution (:모듈 시스템 관련)

• 모듈 해결 전략 설정 (module을 찾기 위해 어디를 봐야할까?)
• classic vs node
  

상대적 vs 비상대적 모듈 import

• 상대적 : /, ./, ../ 중 하나로 시작한다.
• 비상대적 : 이외의 모듈은 모두 비상대적으로 간주된다.
  • baseUrl로 해석되거나, ambient 모듈 선언으로 해석될 수 있다.

• node: moduleResolution을 node로 설정할 경우 node.js 방식으로 모듈을 찾는다.
• classic : 오늘날 대부분 사용하지 않는다.
  • You probably won’t need to use classic in modern code
    

declaration (:d.ts 관련)

• declaration: true ts파일의 d.ts도 컴파일 결과로 만들어진다.

declarationDir (:d.ts 관련)

• 컴파일 결과로 만들어진 d.ts 파일들만 따로 특정 디렉토리에 넣어줄 수 있다.

emitDeclarationOnly (:d.ts 관련)

• emitDeclarationOnly: true 라면 컴파일 결과로 d.ts 파일만 생성된다.

skipLibCheck (외부 라이브러리 관련, d.ts 관련)

• skipLibCheck: true의 경우 d.ts 타입 체크를 생략한다.
• 개발자의 프로젝트에는 타입 문제가 없는데 외부 라이브러리 타입 정의가 잘못되어서 오류가 날 경우 유용한 옵션
• 대부분의 d.ts는 외부용으로 사용되는 것이 일반적이다. (개발자의 프로젝트에서 d.ts를 사용하는 것이 일반적이지 않다. 일반 typescript 프로젝트에서는 type 정의를 ts 파일에서 하고, export, import하는 것이 권장된다.)

tsd 라이브러리

• https://www.npmjs.com/package/tsd
• type 선언에 대한 테스팅 라이브러리 (d.ts 파일 등)
• 테스트 케이스 파일인 .test-d.ts 파일은 실행되지 않고, 컴파일되지 않는다.

사용 방법

1. d.ts 을 만들어서 파일 안에 타입 선언을 해준다. (내가 만들 module이나, function, value에 대한 타입)

declare function _(selector: string): string;

export default _;

2. test 파일을 만들어서 테스트 해준다. (나는 이름을 test.d.ts로 해주었다.)

import { expectType } from 'tsd';

import _ from '../../src/index.d';

expectType<string>(_('string')); 
expectType<number>(_('string')); // ERROR

3. npx tsd를 통해 타입 테스트를 진행한다.

만약 테스트가 통과한다면 아무 설명도 출력되지 않고,
실패했을 경우에만 에러에 대한 로그가 출력된다.

설정

1. package.json에서 설정해줄 수 있다.

{
	"name": "ts-module",
	
	...
	"tsd": {
		...
	}
}

2. 내가 해준 설정

우선 나의 디렉토리 구조는 이렇다.

root 
	📂 __tests__
		📂 @types
			📄 type.test.ts
		
		... 다른 테스트 관련 파일들 (jest 등) 

"tsd": {
		"directory": "./__tests__/@types"
}

@types로 분리한 이유는 테스트 단위를 디렉토리로 묶기 위해서다.

tsd.directory

• 테스트가 여러 파일로 분산되어 있는 경우 테스트 디렉토리를 지정해 줄 수 있다.

다른 유용할 것 같은 설정은 compilerOptions이다.

compilerOptions

• 프로젝트안 tsconfig.json이 존재할 때 override할 수 있다.
• 만약 vscode의 type checker와 설정을 다르게 할 것이라면 유용하게 쓸 수 있을 것 같다.
  (moduleResolution 옵션은 override 불가능)

tsd에서는 어떻게 타입 검사를 할까?

expectType의 구현부는 이와 같다.

/**
 * Asserts that the type of `expression` is identical to type `T`.
 *
 * @param expression - Expression that should be identical to type `T`.
 */
// @ts-expect-error
const expectType = (expression) => {
    // Do nothing, the TypeScript compiler handles this for us
};
exports.expectType = expectType;

// d.ts

/**
 * Asserts that the type of `expression` is identical to type `T`.
 *
 * @param expression - Expression that should be identical to type `T`.
 */
export declare const expectType: <T>(expression: T) => void;

보면 구현되어 있는게 없다. 예상해보면 그냥 type checker에게 맡겨버리는 것이다.

언제 사용하면 좋을까요?

아마도 어려운 타입을 정확하게 설계해야 할 때 유용하지 않을까 싶다.
이번 미션에서 omit이라는 유틸함수를 만들어야했고, 이에 대한 타입도 지정해줘야 했다.
여러 크루 코드를 참고하고, 결론은 이런 결과물이 나왔다.

function omit<T extends object, K extends keyof T>(
    object: T,
    target: K | K[]
): Omit<T, K>

// 첫번째 매개변수로 들어온 객체에서 (object)
// 두번째 매개변수로 들어온 프로퍼티(target)를 제거한 객체를 반환해야한다. 

tsd를 사용하면 타입이 틀렸는지 아닌지 쉽게 확인해볼 수 있는데 여러 assertions(expectType, expectNotType 등)를 활용해보면 정확히 구현했는지 확인할 수 있다.

expectType<Omit<{ a: 'a'; b: 'b' }, 'a'>>(omit({ a: 'a', b: 'b' }, 'a'));
// c를 뺐으니 a, b만 포함해야 된다. 

expectNotType<{ a: 'a'; b: 'b'; c: 'c' }>(
  omit({ a: 'a', b: 'b', c: 'c' }, 'c')
);
// c를 뺐으니 c는 포함되어 있으면 안된다. 

expectError<{ a: 'a'; b: 'b'; c: 'c' }>(
  omit({ a: 'a', b: 'b', c: 'c' }, 'c')
);
// c가 return 타입에 포함되어 있다면 오류가 발생할 것이다. 

또, ts-loader를 쓰는 이유와 비슷하다고 생각하는데, ts-loader는 babel-loader와 달리 타입 체킹도 진행한다. 하지만 vscode에는 type checker가 내장되어 있어서 이미 타입 체킹이 진행되고 있다. 이에 또 ts-loader를 사용하는 이유는 강력한 타입 체킹을 위한 것이라고 생각한다. (vscode type checker가 오류로 인해 제대로 type checking에 실패해서 런타임에 프로그램이 종료되는 경우 아예 차단)

tsd도 비슷한 맥락이 아닐까 😀

참고

• https://typescript-kr.github.io/pages/tsconfig.json.html
• https://velog.io/@sooran/tsconfig.json-제대로-알고-사용하기
• https://typescript-kr.github.io/pages/module-resolution.html
• https://it-eldorado.tistory.com/124
• https://www.typescriptlang.org/tsconfig#include
• https://www.npmjs.com/package/tsd