이펙티브 타입스크립트 (댄 밴더캄 지음) 를 읽고 정리
📍요약
✅@types 의존성 관련 3가지 버전
- 개별 라이브러리 버전
- 그 라이브러리들의 @types 버전
- typescript 라이브러리 버전
✅라이브러리를 업데이트하는 경우, 해당 @types 역시 업데이트해야 함
✅TS로 작성된 라이브러리 : 타입 선언을 자체적으로 포함
✅JS로 작성된 라이브러리 : DefinitelyTyped에 타입 선언을 공개하여 커뮤니티 차원에서 유지 보수
📍실제 라이브러리와 타입 모듈의 버전이 다른 경우
예) 타입 선언의 버전이 더 빠른 경우
react@16.8.6
@types/react@16.8.19 => 타입 정보의 버전이 더 빠름
✅단순히 patch 버전만 다르기 때문에, 타입 선언을 업데이트할 필요는 없지만..
- 타입 선언 자체에도 버그나 누락이 존재할 수 있다
대표적인 4가지 경우를 살펴보면..
1. 라이브러리 버전 > 타입 모듈 버전
✅라이브러리를 업데이트했지만, 실수로 타입 선언은 업데이트하지 않은 경우
타입 모듈을 업데이트하면 해결되지만, 아직 타입 모듈이 준비되지 않은 경우에 2가지 해결책이 존재
- 타입 보강을 활용해 새로 추가된 객체나 함수의 타입 정보를 프로젝트에 직접 추가
- 타입 선언의 업데이트를 직접 작성하고 공개하여 커뮤니티에 기여
2. 라이브러리 버전 < 타입 모듈 버전
✅타입 정보 없이 라이브러리를 사용해오다가 후에 추가하는 경우
- 라이브러리 버전을 업데이트하거나 타입 선언의 버전을 내려서 사용
3. 프로젝트의 typescript 모듈 버전 < 라이브러리에서 필요로하는 TS 버전
✅@types 선언 자체에서 타입 에러 발생하게 된다
- 프로젝트의 typescript 버전을 올리거나, 라이브러리의 타입 선언의 버전을 내린다
⭐타입스크립트의 특정 버전에 대한 타입 정보를 설치할 수 있다
npm install -D @types/lodash@ts3.1
4. @types 의존성 중복되어 충돌
✅두 라이브러리의 버전이 다르면, 최신화해서 버전을 통일한다
✅타입스크립트로 작성된 라이브러리들은 자체적으로 타입 선언을 포함하여 번들링한다
// package.json
{
"name": "left-pad",
"version": "1.3.0",
"types": "index.d.ts", // 자체적 타입 선언
// ...
}
✅자체 타입 선언 번들링 방식도 부수적인 4가지 문제점을 가진다
1. 작성한 타입 선언에 에러가 있는데 타입 보강으로 해결 불가 (또는 TS 버전이 올라가면서 에러가 발생하는 경우)
- @types 방식이었다면, 라이브러리 자체의 버전에 따라 타입 선언 버전을 맞출 수 있다
2. 프로젝트의 타입 선언이 다른 라이브러리의 타입 선언에 의존
- 자체 선언했음에도 다른 @types 모듈 설치해야 하는 사태가 벌어짐..
3. 프로젝트 과거 버전의 타입 선언에 문제가 있는 경우
- 과거 버전으로 돌아가 패치 업데이트를 하게 되면 타입 선언만 변경하는 것이 아니게 됨
- @types 모듈을 관리하는 DefinitelyTyped의 경우 동일 라이브러리의 여러 버전의 타입 선언을 동시에 유지보수 가능
4. 타입 선언의 패치 업데이트를 자주 챙기기 힘든 문제(리소스 부족)
- @types 는 커뮤니티 기반으로 작업량 감당 가능
📍공식적인 권장사항
✅타입스크립트로 작성된 라이브러리에만 타입 선언을 라이브러리에 포함
- 컴파일러 옵션에서 declaration 설정 활용
✅자바스크립트로 작성된 라이브러리는 타입 선언을 DefinitelyTyped에 공개
- 컴파일러 대신 사람이 직접 타입 선언 파일을 작성하면 오류가 발생할 수 있음
- 커뮤니티 내에서 관리하는것이 바람직