아이템 45 devDependencies에 typescript와 @types 추가하기
npm에선 package.json을 통해 라이브러리들의 버전을 지정한다.
npm은 세 가지 종류의 의존성을 구분해서 관리한다.
1. dependencies
현재 프로젝트를 실행하는데 필수적인 라이브러리들이 포함됨.
런타임에 어떤 라이브러리가 사용된다면 해당 항목에 포함되어야 함.
해당 프로젝트를 npm에 공개하여 타인이 다운받게 되면 이 하위의 라이브러리들도 다운받게 됨.
2. devDependencies
현재 프로젝트의 개발과 테스트에서 필요하지만 런타임에는 필요없는 라이브러리들이 포함됨.
테스트 프레임워크들과 같은 경우 런타임 시 필요없기 떄문에 이 하위에서 관리하면 됨.
3. peerDependencies
런타임에 필요하기긴 하지만, 의존성을 직접 관리하지 않는 라이브러리들이 포함됨.
(주로 사용하는 것은 1,2 이므로 이 정도면 정리)
타입스크립트는 개발 도구일 뿐 타입 정보는 런타임에 존재하지 않음!
즉, 타입스크립트와 관련된 라이브러리들은 일반적으로 devDependencies에 속해야 함.
모든 타입스크립트 프로젝트에서 공통적으로 고려해야 할 의존성 두 가지.
1. 타입스크립트 자체 의존성
시스템 레벨의 설치는 추천하지 않음.
팀원들 모두가 동일한 버전을 설치한다는 보장이 없고, 프로젝트를 셋업할 때 별도의 단계가 추가되기 때문.
즉, 타입스크립트를 시스템 레벨로 설치하기 보단, devDependencies에 넣는 것이 좋음.
이렇게 하면 npm i 명령어를 통해 모두가 동일한 버전의 타입스크립트를 설치할 수 있음.
2. 타입 의존성(@types)
사용하려는 라이브러리에 타입 선언이 포함되어 있지 않아도, DefinitelyTyped에서 타입 정보를 얻을 수 있음.
위의 타입 정의들은 npm레지스트리의 @typed 스코프에 공개됨.
타입 정보만 포함하고 있으며 구현체는 포함하지 않음. 원본 라이브러리가 dependencies에 있어도 타입 정보는 dev에 저장되어야 함.
이 방식이 항상 유효한 것은 아니고 아이템 46에서 설명.
아이템 46 타입 선언과 관련된 세 가지 버전 이해하기
타입스크립트의 의존성 관리는 힘들다.
다음 세 가지를 고려해야 한다.
1. 라이브러리의 버전
2. 타입 선언의 버전
3. 타입스크립트의 버전
세 가지 버전 중 하나라도 맞지 않으면, 의존성과 상관없어 보이는 곳에서 엉뚱한 에러가 발생할 수 있다.
이렇게 발생한 에러의 원인 파악 및 수정을 위해서는 메커니즘을 이해해야 한다.
이 메커니즘은 나중에 외부에 프로젝트 내에서 작성한 타입 선언을 공개해야 하는 시점이 올 때 버전과 관련된 제대로 된 결정을 내릴 수 있다.
공식적인 권장사항은 라이브러리가 타입스크립트로 작성된 경우만 타입 선언을 라이브러리에 포함하는 것.
실제로 타입스크립트 컴파일러가 타입 선언을 대신 생성해 주기 때문.
아이템 47 공개 API에 등장하는 모든 타입을 익스포트하기
타입스크립트를 사용하다 보면, 서드파티의 모듈에서 익스포트되지 않은 타입 정보가 필요한 경우가 생김. (어떤 경우가 있을까?)
(웬만하면 필요한 타입을 참조하는 방법을 찾을 수 있다고 함.)
ex.) 어떤 타입을 숨기기 위해 의도적으로 익스포트하지 않은 경우
interface SecretName {
first: string,
last: string
}
interface SecretSanta {
name: SecretName,
gift: string
}
export function getGift(name: SecretName, gift: string): SecretSanta {
///...
}해당 라이브러리 사용자는 SecretName또는 SecretSanta를 직접 임포트할 수 없고 getGift만 임포트 가능함.
그러나 타입들은 익스포트된 함수 시그니처에 등장하기 때문에 추출할 수 있음.
Parameters와 ReturnType 제너릭 타입을 사용하는 것을 통해 추출할 수 있음.
type MySanta = ReturnType<typeof getGift>; // SecretSanta
type MyName = Parameters<typeof getGift>[0]; // SecretName위와 같이 써보진 않았지만 공개 API의 매개변수에 놓이는 순간 타입은 노출됨.
아이템 48 API 주석에 TSDoc 사용하기
일반적으로 프로그래밍 언어들에 사용되는 주석은 //와 /***/가 있음.
후자를 사용하면, 툴팁에서 해당 주석을 보여주지만 인라인 주석은 그렇지 않음.
자바스크립트에선 각각 인라인 주석과 JSDoc스타일의 주석이라고 부름. TS관점에선 TSDoc이라고 부른다고 함.
TSDoc 주석은 마크다운 형식으로 작성되어 볼드체 등의 기능을 작성할 수 있음.
훌륭한 주석은 간단히 요점만 언급
아이템 49 콜백에서 this에 대한 타입 제공하기
타입스크립트는 자바스크립트의 상위집합.
자바스크립트의 주요 개념인 this 바인딩의 원리를 반드시 제대로 파악하고 있어야 함.
콜백에서 this를 사용해야 한다면, 타입 정보를 명시해야 함.
아이템 50 오버로딩 타입보다는 조건부 타입을 사용하기
function double<T extends number | string>(
s: T
): T extends string ? string : number;
function double(s: any) { return x + x; }위와 같이 자바스크립트의 삼항 연산자처럼 사용할 수 있음.
제네릭 타입을 사용하는 것과 유사하지만 반환 타입이 더 정교해짐.
아이템 51 의존성 분리를 위해 미러 타입을 사용하기
작성 중인 라이브러리가 의존하는 라이브러리의 구현과 무관하게 타입에만 의존한다면,
필요한 선언부만 추출하여 작성 중인 라이브러리에 넣는 것(미러링)을 고려해 보는 게 좋음.
필수가 아닌 의존성을 분리할 때는 구조적 타이핑을 사용하면 됨.
아이템 52 테스팅 타입의 함정에 주의하기
프로젝트를 공개하려면 테스트 코드를 작성하는 것은 필수.
타입 선언도 테스트를 거쳐야 함.
타입 선언을 테스트하기는 매우 어려움.
