TypeScript, 오호라!
TypeScript를 프로젝트의 주 언어로 사용한지 일 년 쯤 되어 간다. 정확히 말하자면 Node.js를 기반으로 하는 JavaScript를 사용하다가 TypeScript로 전환했다는 것이 맞겠다. 프론트엔드와 백엔드를 하나의 언어로 개발할 수 있다는 점과, 배포를 위한 런타임 구성이 간단하거나 아에 필요가 없다는 점 말고도 이유가 많았지만, 찾아보면 다 나오는 말들이니 생략하겠다. 하지만 이 말은 꼭 해야겠다. 많은 이유들 중 가장 큰 것은 JavaScript의 수퍼셋인 TypeScript는 - 자바에서는 당연한 것이었지만 - JavaScript의 type에 대한 유연함(?)이 가져다 주는 잠재적인 문제들을 상당수 해결해 줬다는 점이다. 정적분석을 통해 버그를 미리 발견하고 VS Code의 편리한 기능을 십분활용하게 된 것은 덤이다.
단위테스트 폴더를 구분하고 싶어요, 그런데
TypeScript가 어느 정도 익숙해지고 나자 '단위테스트는 어떻게 할까?' 라는 질문 아닌 질문이 생겼다. 당연하게도 해야하는 것이고 하면 되는데 말이다. 그럼에도 미루고 미루다 - 사전 조사, Jest, Vitest, .... 들 중 어느 것을 선택하냐는 - 단위테스트를 위한 프레임워크를 Vitest로 결정하고 마침 개발 중이던 HashTable에 적용하기로 했다.
십수 년간 익숙하게 사용해 온 Java 프로젝트 구조를 떠올리면서 src와 tests로 폴더를 구분하기로 했다. 물론 빌드 후 JavaScript는 dist 폴더로 모아주고 여기에 tests 폴더의 ts 파일들은 넘기고 싶지 않았다. 이 외에도 자잘한 이유들이 있어 tsconfig.json파일에 baseUrl, rootDir, outDir 그리고 paths를 사용하고 있는데 이를 포기할 순 없었다. 문제는 여기서 발생했다.
위에 캡처한 그림에서 보는 것과 같이 테스트 파일(*.test.ts)에 import한 테스트 대상 모듈의 형식 선언을 찾을 수 없다고 내뱉는다. 물론 @src라는 alias를 사용하지 않고 일반적인 상대경로를 적어주면 군말없다. 그런데 @src를 포기하면 내가 당초 그렸던 큰 그림이 수포로 돌아간다. 우선은 src 밑으로 tests를 밀어 넣거나, 아니면 tests를 src와 분리하되 일일이 상대경로를 계산해서 넣어줘야 한다. 그러기 싫어서 tsc-alias 모듈을 쓰는 건데 말이다.
왜 그럴까?
방법을 찾고나니 당연하게도 '그렇지, 그렇고 말고' 했지만 찾기까진 답답했다. (내가 만든) 문제의 방법을 밝히기 전에 우선 왜 그럴까? 부터 밝혀 보도록 하자. JavaScript의 수퍼셋 언어인 TypeScript를 지원하는 개발툴로는 VS Code를 쓴다. 당연하게도. 그리고 VS Code는 TypeScript로 작성된 코드에 대해 어떤 식으로 접근해야 할지를 미리 지정한 설정 파일, tsconfig.json을 프로젝트 단위 마다 갖고 있다.
이 파일의 내용 중 앞서 언급했던 baseUrl, rootDir, outDir 그리고 paths와 include가 VS Code의 동작 범위를 결정한다. 이들 중에서 특히 rootDir과 include의 내용이 중요했다. 아래는 내가 설정했던 내용으로 문제가 됐던 것이다.
프로젝트 폴더를 baseUrl로 삼고, ts 소스는 ./src 폴더 이하를 빌드 후 js파일은 ./dist에 저장하라는 의미이다. 그리고 복잡한 상대경로를 직관적인 가상의 절대경로로 바꿔주는 paths에 @src를 rootDir과 연결해줬다. VS Code는 이 범위 내에서 TypeScript에 대한 지원을 하게된다. 즉 이 설정대로라면 ./tests 폴더 하위의 ts 파일에 대해서는 가장 기본적인 형식점검부터 시작해서 그 외 다양한 편의기능을 지원하지 못하게 되는 것이다. 시행착오를 겪었던 것 중 하나만 밝히자면 rootDir을 rootDirs로 바꾸고 "./tests"를 추가해줘봤다. 동작은 하지만 내가 원하는 큰그림하고는 거리가 멀었다. ./dist 폴더에 src와 tests 하위 폴더가 생겨버린 것이다.
조금 더 생각해보자, ......
'VS Code가 참고하는 설정파일과 tsc가 참조하는 설정파일을 구분하면 되지 않을까?'라는 생각에 도달하게 됐다. 그래서 tsc 명령어의 옵션을 찾아 보니 -p가 떡하니 있는 것이 아닌가!
개발환경과 빌드환경을 구분하면 돼!
이젠 프로젝트 폴더에 tsconfig.json과 tsconfig.build.json 두 개의 파일이 있다. tsconfig.json은 개발을 진행하는 동안 VS Code의 각종 지원을 받기 위한 설정파일이고 tsconfig.build.json은 tsc를 통해 src/**/*.ts 파일들을 js 파일로 변환해 dist에 보내주기 위한 설정파일이다.
이렇게 두 개로 분리하고 나니 이슈가 됐던 ts(2307)이 사라졌을 뿐 아니라, 새로운 이슈(???) 아니지, 테스트 프로그램도 ts 답게 쓰라는 격려의 메시지들을 만나게 됐다.
SoC와 TypeScript
지난 해 가을부터 라즈베리파이를 비롯한 SoC 보드에 임베디드 리눅스를 올리고 여기서 동작하는 앱, 서버 등의 프로그램들을 개발하는 다수의 프로젝트를 진행하고 있다. 이들 모두 TypeScript로 개발했다. 성능이슈는 딱히 없었다. 앞으로도 없길 바란다.
용도별로 분할한 설정 파일들
앞서 몇 번의 시행착오를 거쳐 안착한 설정은 다음과 같다. 우선 두 개의 파일로 VS Code, TSC를 위한 설정를 분리, 구분했다. 그러고 한참 후에 다시 보니 두 개 파일이 중복된 내용이 상당하다. 그래서 공통되는 부분을 tsconfig.base.json으로 따로 뺐다.
'일하는 중에' 카테고리의 다른 글
TypeScript, Unit Test를 위한 환경 만들기 (5) | 2024.09.07 |
---|---|
TypeScript, Unit Test 중 코드 커버리지 실패 원인과 해결 (1) | 2024.09.04 |
Apache Phoenix Query Server를 활용한 프론트엔드 개발환경 꾸미기 (7) | 2020.08.10 |
증강분석(augmented analytics)과 워크스페이스(workspaces) (0) | 2020.06.25 |
화면설계서 작성을 위한 최적의 도구, PowerMockup (0) | 2020.05.09 |