Item 61 의존성 관계에 따라 모듈 단위로 전환하기

Item 58에서 모던 JS로 전환하는 방법을 알아보았고, Item 60에서 빌드 과정에 TS를 통합하고 테스트까지 수행하는 방법을 다뤘다. 이제 본격적으로 JS를 TS로 전환하는 단계를 알아보자.

점진적 마이그레이션을 할 때는 모듈 단위로 각개격파하는 것이 이상적이다.

한 모듈을 골라서 타입 정보를 추가하면, 해당 모듈이 의존(import)하는 모듈에서 비롯되는 타입 오류가 발생한다. 이걸 방지하려면 다른 모듈에 의존하지 않는 최하단 모듈부터 작업을 시작해 최상단을 마지막에 작업해야 한다.
프로젝트에 존재하는 모듈은 서드파티 라이브러리에 의존하지만 서드파티 라이브러리는 해당 모듈에 의존하지 않는다. 따라서 서드파티 라이브러리 타입 정보를 먼저 해결해야 하는데, 일반적으로 @types 모듈을 설치해주면 된다.
외부 API를 호출하는 경우 외부 API의 타입 정보도 추가해야 한다. API 스펙을 기반으로 타입 정보를 생성해야 한다(Item 35).
모듈 단위 마이그레이션을 시작하기 전, 모듈 간 의존성 관계를 시각화해보면 도움이 된다. madge라는 도구를 이용해 의존성 관계도를 시각화할 수 있다.
마이그레이션 과정에서는 타입 정보 추가만 하고, 리팩터링을 해선 안 된다. 나중에 할 수 있도록 목록을 유지하자.

Item 59에서 TS로 전환하며 발견하게 되는 일반적인 오류들을 다뤘는데, 여기서는 미처 다루지 못한 또 다른 오류들을 알아본다.

선언되지 않은 클래스 멤버
- 생성자에서 this로 참조한 멤버 변수는 멤버 필드로 추가해야 한다.
타입이 바뀌는 값
- 한번에 생성되지 않은 값들이 있다면 객체 리터럴로 한번에 생성해주자.
- 곤란하다면 타입 단언문을 사용하는 방법도 있다. 하지만 나중엔 Item 9를 참고해 문제를 해결해야 한다.
- JS 상태에서 JSDoc과 @ts-check를 사용해 타입 정보를 추가한 상태라면(Item 59), TS로 전환하는 순간 타입 정보가 '무효화'된다는 것을 주의하자. 즉, TS로 전환하면 그 두개는 작동하지 않는다.

마이그레이션의 첫 단계는 서드파티 모듈과 외부 API 호출에 대한 @types를 추가하는 것이다.
의존성 관계도의 아래에서부터 위로 올라가며 마이그레이션을 하면 된다. 첫 번째 모듈은 보통 유틸리티 모듈이다. 의존성 관계도를 시각화하여 진행 과정을 추적하자.
이상한 설계를 발견하더라도 리팩터링을 하면 안된다. 마이그레이션 작업은 TS 전환에 집중해야 하고, 나중의 리팩터링을 위해 목록을 만들어 두는 것이 좋다.
TS로 전환하며 발견하게 되는 일반적인 오류들을 놓치지 말아야 한다. 타입 정보를 유지하기 위해 필요에 따라 JSDoc 주석을 활용해야 할 수도 있다.

Last updated 1 year ago