45. devDependencies에 typescript와 @types 추가하기

45-1. 의존성의 종류

• dependencies
  • 현재 프로젝트를 실행하는 데(런타임에서) 필수적인 라이브러리
  • 전이 의존성(사용자가 프로젝트 설치 시 함께 설치) 가짐
• devDependencies
  • 개발, 테스트하는 데 사용되지만 런타임에서는 필요 없는 라이브러리
  • npm install —save-dev 라이브러리이름
• peerDependencies
  • 런타임에 필요하긴 하지만, 의존성을 직접 관리하지 않는 라이브러리

45-2. 고려해야 할 의존성

• 타입스크립트 자체 의존성 고려
  • 타입스크립트를 시스템 레벨로 설치하기보다는 devDependencies 에 넣기
• 타입 의존성(@types) 고려
  • 원본 라이브러리가 dependencies 에 있더라도 @types 의존성은 devDependencies 에서 관리하기

46. 타입 선언과 관련된 세 가지 버전 이해하기

• (기본개념) 시멘틱 버전 규칙

46-1. 타입 선언과 관련된 세 가지 버전

• 라이브러리의 버전
• 타입 선언(@types)의 버전
• 타입스크립트의 버전

46-2. 생길 수 있는 문제 상황과 해결

기본적으로 둘 중 하나의 버전을 올리거나 내림으로써 해결할 수 있다.

• 라이브러리 버전 > 타입 선언 버전

  • 보강 기법으로 타입 정보 추가

• 라이브러리 버전 < 타입 선언 버전

• 프로젝트에서 사용하는 타입스크립트 버전 < 라이브러리에서 필요로 하는 타입스크립트 버전

  • declare module 선언으로 타입 정보 없애기

  • typeVersions 지원하는 경우 특정 버전에 대한 타입 정보 설치하기

    npm install —save-dev @types/라이브러리이름@ts버전

• @types 의존성 중복

  • npm ls @types/중복된 타입선언명 으로 추적 가능

  • 번들링 (자체적으로 타입 선언을 포함)

    //package.json
    {
    	"name": "라이브러리이름",
    	...
    	**"types": "index.d.ts" // 번들링**
    	...
    }
    

46-3. 번들링의 문제점

• 번들된 타입 선언에 보강 기법으로 해결할 수 없는 오류가 있을 경우, 또는 공개 시점보다 타입스크립트 버전이 올라가면서 오류가 발생한 경우
• 프로젝트 내의 타입 선언이 다른 라이브러리의 타입 선언에 의존하는 경우
• 프로젝트의 과거 버전의 타입 선언에 문제가 있는 경우
• 타입 선언의 패치 업데이트를 자주 하기 어려움

→ JS로 작성된 라이브러리라면 DefinitelyTyped에 공개, TS로 작성된 라이브러리라면 번들링

47. 공개 API에 등장하는 모든 타입을 익스포트하기

• 공개 메서드의 모든 타입은 어차피 추출 가능하므로 모두 익스포트하기

48. API 주석에 TSDoc 사용하기

48-1. JSDoc/TSDoc 형태의 주석 달기

• 예시
• 편집기가 주석 정보를 표시
• 마크다운 문법 사용 가능
• @param, @return 구문 사용하기
• 주석에 타입 정보를 포함하지 않기