build(tsconfig): introduce tsconfig.build.json

[jjangga0214]

안녕하세요.

examples 를 보던 중 다음과 같은 오류를 발견했습니다.
(node_modules 에 node-kakao 가 있을리 없으니) 해당 모듈을 찾을 수 없다는 오류였습니다.

examples 은 사용 예시일 뿐이고 publish 대상도 아니므로, 오류의 여부와 관계없이 로컬에서 그냥 snippet 을 작성하여 commit 하셨을 줄로 짐작합니다.

하지만 장기적으로 유지보수해가는 측면에서, 아무리 examples 이라도

1. compiler 가 잡아낼 수 있는 오류가 있는지 검사할 수 없다.
2. runtime 에 문제가 생길지를 검증하는 차원에서 실행해 볼 수 없다. (흔적을 남기지 않는 ts-node 등의 사용이 적합하겠죠.)
3. 사용자들이 clone 을 뜨고(PR 을 위함이 아니라 복붙대신 example 을 한번에 다운로드 받기 위함) 바로 이것저것 조금씩 변경해보고 만져보기 부적절하다.

라는 점은 꽤나 불편하다고 생각했습니다. 코드를 검증하려면 항상 따로 파일을 생생해봐야 한다는 뜻이니까요.

1번과 같은 경우도 CI 나 로컬에서 tsc --noEmit 정도만 해줘도 #458 과 같은 변경이 필요함을 훨씬 빨리 알아챌 수 있었을 텐데요.

해서, 이 문제들을 해결하기 위해

A. baseUrl 과 paths 를 도입했습니다. 따라서 node_modules 에 node-kakao 가 존재하지 않아도 컴파일러 차원에서 module resolution 이 가능합니다.
B. ts-node 가 (매번 CLI option 입력없이도) tsconfig-paths/register 를 --require 하도록 했습니다 (ts-node 설정 문서). tsconfig.json 의 paths 를 보고 인식할 수 있습니다.
C. tsconfig.json 에서 include 와 exclude 를 삭제했습니다. 대개 IDE 는 (특히 vscode 는 절대적으로) tsconfig.json 를 바라봅니다.
개발환경에서는 examples 가 exclude 되지 않아야 (include 되어야) IDE 가 타입 검증을 할 수 있습니다. 이는 tests 도 마찬가지 입니다. 따라서 tsconfig.json 은 프로젝트의 모든 .ts 파일을 아우르도록 했습니다.
D. tsconfig.build.json 을 생성했습니다. build 시에는 해당 설정을 이용하도록 했습니다.

P.S. 테스트 파일은 tests/**/*.test.ts 인데, tsconfig.json 은 **/*.spec.ts 을 exclude 하더군요. 그래서 **/*.test.ts 와 tests 를 추가했습니다. (tests/**/*.test.ts 와 같이 하나의 경로만 추가하거나 **/*.spec.ts 을 삭제하지 않은 이유는 나중에 test 파일 배치 규칙이 변경되었을때에도 유연하게 대응하도록 하기 위함입니다.) (include가 명시되었을시, exclude 는 include 대상에서 filtering 하는 방식이라 이미 include 에 src/**/* 가 명시된 이상 최상위 디렉토리인 tests 등을 exclude 하는 것이 무의미하긴 하지만, 그래도 dist 도 동일한 입장에도 이미 exclude 에 존재하고 있었으므로 변경의 유연성 측면에서 추가하였습니다.)

P.S.2. ts-node 설정에 swc 사용을 추가했습니다 (ts-node 설정 문서). 해당 설정으로 ts-node 는 내부적으로 tsc 대신 swc 를 사ㅇ합니다. swc 는 Rust 로 쓰인 (그래서 빠른) babel 로 생각하면 됩니다. 아무래도 개발환경에서는 소스를 수정하고 다양한 (수동, 자동) 테스트를 여러번 거치게 되므로 해당 설정이 유용하다 생각합니다. swc 는 아직(미정) type checking 을 지원하지 않으므로, IDE 가 있음에도 한번 더 검증하고자 하는 경우 tsc --noEmit 한번 실행해주면 됩니다.

[JellyBrick]

https://typestrong.org/ts-node/docs/transpilers/#bundled-swc-integration

• In transpile-only mode, we skip type checking to speed up execution time.

swc를 사용하기 위함외에, 트랜스파일링 전용 모드로 설정해야만 하는 이유가 있나요?

[jjangga0214]

문서에는 명확하게 명시되어 있지 않지만, --transpiler 옵션은 --transpileOnly=true 여야만 가능합니다.

https://github.com/TypeStrong/ts-node/blob/5643ad64cf39ee0dfa2a9323e8d1dd9f400e5884/src/index.ts#L209-L212

  /**
   * Specify a custom transpiler for use with transpileOnly
   */
  transpiler?: string | [string, object];

https://github.com/TypeStrong/ts-node/blob/5643ad64cf39ee0dfa2a9323e8d1dd9f400e5884/src/index.ts#L527-L531

  if (options.transpiler) {
    if (!transpileOnly)
      throw new Error(
        'Custom transpiler can only be used when transpileOnly is enabled.'
      );

ts-node 공식 문서에서는 다음과 같이 표현하고 있습니다.

What is the difference between a compiler and a transpiler?

For our purposes, a compiler implements TypeScript's API and can perform typechecking. A third-party transpiler does not. Both transform TypeScript into JavaScript.

비록 일반적으론 tsc 같은 경우도 transpiler 라고 해도 이론상 문제는 없지만, ts-node 에서 사용하는 용어 정의에 따라면 transpiler 란 type-check 기능이 없는 프로그램을 뜻합니다. 그래서 애초에 3rd party compiler/transpiler 설정을 나눠놓았습니다.

(앞서 서술했다시피 swc 는 type-checking 기능을 구현중이고, 적어도 수개월 후 완성가능할 것으로 보이며, 아직 제공하지는 않습니다. swc-project/swc#571)

따라서 용어 그대로 --transpiler 와 --transpileOnly=false 를 동시 설정가능하려면 compiler 에게는 type checking 을 맡기고(e.g. tsc --noEmit), transpiler 에게 transpiling 을 맡겨야 합니다.

그런데, tsc 의 type checking 은 너무 느립니다. 얼마나 느리냐면 (벤치마크는 없지만 기억상 제 이전 프로젝트에서는) tsc --noEmit + swc 조합과 tsc 를 비교해서 차이가 나긴 해도 크지 않습니다. 따라서 사실상 incremental 하게 type 을 check 해야 하는데 (--incremental option 과 --noEmit 의 병용), 최근까지는 tsc 가 지원하지 않다가 얼마 전 가능해졌습니다. (microsoft/TypeScript#39122).

따라서 --transpiler 와 --transpileOnly=false 의 병용이 개인적으로는 이론적으로 가능하다보는데, 안타깝게도 ts-node 가 --incremental 옵션 자체를 지원하지 않습니다. (TypeStrong/ts-node#817) .tsbuildinfo 파일 자체를 저장하지 않는거죠.

Workaround 로 type-checking 을 transpiling+execution 과 병렬적으로(e.g. npm:concurrently 돌리는 방법이 있으나 터미널이 지저분해지는 단점이 있고, IDE 에서 type-checking 이 다 되는 이상 굳이 "매번" 실행할 필요는 느끼지 못하였습니다.

그래서, 개인적으로 CI 에서 type checking 을 실행하는 것을 추천드립니다.

[jjangga0214]

94bf42f: ts-node 설정이 tsconfig.json 에 있어야 하는데, 실수로 package.json 에 적었던 문제를 수정했습니다.

[jjangga0214]

여담) good first issue 는 관례적으로 해당 프로젝트에 대해 깊은 지식 (도메인, 디자인, 아키텍처 등등 프로젝트 마다 다른 특수한 내용) 이 비교적 적어도, 기여가 가능할만한 이슈에 라벨링하는 것으로 알고 있습니다. 어떤 개발자가 특정 프로젝트에 처음으로 기여하고자 할때 부담없이 해결을 시도할 만한 이슈라는 뜻으로 good first issue 라는 이름을 지었다 합니다. Hacktoberfest 등에서 contribution 을 장려하는 데에도 사용됩니다. (참고: https://github.blog/2020-01-22-how-we-built-good-first-issues/)

본 PR 을 긍정적으로 평가(good) 하시는 뜻으로 사용해주셨다면 정말로 감사합니다.
하지만, 비록 제가 각 개인 및 집단의 라벨 사용 기준에 대해 토를 달 수는 없지만, 관례적 사용과는 다소 동떨어진 것으로 느껴집니다.
혹여나 해서 말씀드립니다!