📄 Item44 ~ 48

Item44. 타입 커버리지를 추적하여 타입 안전성 유지하기

• npm의 type-coverage 패키지를 활용하여 any를 추적할 수 있는 몇 가지 방법이 있다.

$ npx type-coverage
9985 / 10117 98.69%

• 위와 같은 결과는 해당 프로젝트의 10,117개 심벌 중 9,985개(98.69%)가 any가 아니거나 any의 별칭이 아닌 타입을 가지고 있음을 알 수 있다.

$ npx type-coverage --detail
path/to/code.ts:1:10 getColumnInfo
path/to/module.ts:7:1 pt2

• 위와 같이 --detail 플래그를 붙이면, any 타입이 있는 곳을 모두 출력해준다.
  • 이를 통해 미처 발견하지 못한 any의 근원지를 찾을 수도 있다.
• 서드파티 라이브러리로부터 비롯되는 any 타입은 몇 가지 형태로 등장할 수 있지만 가장 극단적인 예는 전체 모듈이 any 타입을 부여하는 것이다.

declare module 'my-module';

• 위와 같은 선언으로 my-module에서 어떤 것이든 오류 없이 import 할 수 있다.
  • import한 모든 심벌은 any 타입이고, import한 값이 사용되는 곳마다 any 타입을 양산하게 된다.

import { someMethod, someSymbol } from 'my-module'; // 정상

const pt1 = {
  x: 1,
  y: 2,
}; // 타입이 {x: number, y: number}

const pt2 = someMethod(pt1, someSymbol); // 정상, pt2의 타입이 any

• 서드파티 라이브러리로부터 비롯되는 any의 또 다른 형태는 타입에 버그가 있는 경우이다.
  • 선언된 타입과 실제 반환된 타입이 맞지 않는다면 어쩔 수 없이 any 단언문을 사용해야 한다.
  • 그러나 나중에 라이브러리가 업데이트되어 함수의 선언문이 제대로 수정된다면 any를 제거해야 한다.

---

📌 정리

• noImplicityAny 가 설정되어 있어도, 명시적 any 또는 서드파티 타입 선언(@types)을 통해 any 타입은 코드 내에 여전히 존재할 수 있다는 점을 주의해야 한다.
• 작성한 프로그램의 타입이 얼마나 잘 선언되었는지 추적해야 한다. 추적함으로써 any의 사용을 줄여 나갈 수 있고 타입 안전성을 꾸준히 높일 수 있다.

---

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

(1) npm의 세 가지 종류의 의존성

• dependencies
  • 현재 프로젝트를 실행하는 데 필수적인 라이브러리들이 포함
  • 프로젝트의 런타임에 lodash가 사용된다면 여기에 포함되어야 함
  • 프로젝트를 npm에 공개하여 다른 사용자가 해당 프로젝트를 설치한다면, dependencies에 들어 있는 라이브러리도 함께 설치될 것이다.
  • 이러한 현상을 전이(transitive) 의존성이라고 한다.
• devDependencies
  • 현재 프로젝트를 개발하고 테스트하는 데 사용되지만, 런타임에는 필요 없는 라이브러리들이 포함
    • 예를 들어, 프로젝트에서 사용 중인 테스트 프레임워크가 여기에 포함된다.
  • 프로젝트를 npm에 공개하여 다른 사용자가 해당 프로젝트를 설치한다면, devDependencies에 포함된 라이브러리들은 제외된다.
• peerDependencies
  • 런타임에 필요하긴 하지만, 의존성을 직접 관리하지 않는 라이브러리들이 포함
    • 단적인 예로 플러그인을 들 수 있다.
  • jQuery의 플러그인은 다양한 버전의 jQuery와 호환되므로 jQuery의 버전을 플러그인에서 직접 선택하지 않고, 플러그인이 사용되는 실제 프로젝트에서 선택하도록 만들 때 사용한다

(2) typescript 환경에서 npm 의존성 관리

🏁 타입스크립트 자체 의존성 고려

• 타입스크립트를 시스템 레벨로 설치할 수도 있지만, 다음 두 가지 이유 때문에 추천하지 않는다.
  • 팀원들 모두가 항상 동일한 버전을 설치한다는 보장이 없다.
  • 프로젝트를 셋업할 때 별도의 단계가 추가된다.
• 따라서 타입스크립트를 시스템 레벨로 설치하기보다는 devDependencies에 넣는 것이 좋다.
• 여기에 포함된다면 npm install을 실행할 때 팀원들 모두 항상 정확한 버전의 타입스크립트를 설치할 수 있다.

🏁 타입 의존성(@types)을 고려

• 사용하려는 라이브러리에 타입 선언이 포함되어 있지 않아도, DefinitelyTyped에서 타입 정보를 얻을 수 있다.
• DefinitelyTyped의 타입 정의들은 npm 레지스트리의 @types 스코프에 공개된다.
• 참고로, @types 라이브러리는 타입 정보만 포함하고 있으며 구현체는 포함하지 않는다.
• 원본 라이브러리 자체가 dependencies에 있더라도 @types 의존성은 devDependencies에 있어야 한다.

{
    "devDependencies": {
        "@types/react": "^16.8.19",
        "typescript": "^3.5.3"
    },
    "dependencies": {
        "react": "^16.8.6"
    }
}

• 위 예제는 런타임에 @types/react와 typescript에 의존하지 않겠다는 것이다.
• 만일 런타임에 @types가 필요한 경우라면 별도의 작업이 필요할 수 있다.

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

(1) 실제 라이브러리와 타입 정보의 버전이 별도로 관리되는 방식의 문제점

• 라이브러리를 업데이트했지만 실수로 타입 선언은 업데이트하지 않은 경우
  • 업데이트해야 할 타입 선언의 버전이 아직 준비되지 않은 경우 보강 기법으로 사용하려는 새 함수와 메서드의 타입 정보를 프로젝트 자체에 추가하거나 타입 선언의 업데이트를 직접 작성하고 공개하여 커뮤니티에 기여한다.
• 라이브러리보다 타입 선언의 버전이 최신인 경우
  • 라이브러리와 타입 선언의 버전이 맞도록 라이브러리 버전을 올리거나 타입 선언의 버전을 내린다.
• 프로젝트에서 사용하는 타입스크립트 버전보다 라이브러리에서 필요로 하는 타입스크립트 버전이 최신인 경우
  • 타입스크립트의 최신 버전을 사용하자.
• @types 의존성이 중복될 수 있다.

(2) 번들링 방식의 문제점

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

---

📌 정리

• 타입 선언을 라이브러리에 포함하는 것과 DefinitelyTyped에 공개하는 것 사이의 장단점을 이해해야 한다.
• 타입스크립트로 작성된 라이브러리라면 타입 선언을 자체적으로 포함하고, 자바스크립트로 작성된 라이브러리라면 타입 선언을 DefinitelyTyped에 공개하는 것이 좋다.

---

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

• 공개 메서드에 등장한 어떤 형태의 타입이든 익스포트하자.
  • 어차피 라이브러리 사용자가 추출할 수 있으므로, 익스포트하기 쉽게 만드는 것이 좋다.

Item48. API 주석에 TSDoc 사용하기

• 사용자를 위한 문서라면 JSDoc 스타일의 주석으로 만드는 것이 좋다.
  • 왜냐하면 대부분의 편집기는 함수가 호출되는 곳에서 함수에 붙어 있는 JSDoc 스타일의 주석을 툴팁으로 표시해 주기 때문이다.
• 주석을 수필처럼 장황하게 쓰지 않도록 주의해야 한다.
  • 훌륭한 주석은 간단히 요점만 언급한다.
• JSDoc에는 타입 정보를 명시하는 규칙(@param {string} name ...)이 있지만, 타입스크립트에서는 타입 정보가 코드에 있기 때문에 TSDoc에서는 타입 정보를 명시하면 안 된다.