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 한번 실행해주면 됩니다.

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