.d.ts 는 js 의 타입정의를 위한 파일이다!!
.d.ts 는 두가지 종류가 있다. 1. 모듈 선언, 2. 전역 선언.
import , export 구문이 들어간 것으로, JS모듈을 위해 존재하는 것. statement 앞에 자동으로 export 가 붙는다.import , export 구문이 들어가지 않은 것으로, 전역으로 동작하는 JS코드의 타입 선언을 위해 존재하는 것. statement 앞에 자동으로 declare 가 붙는다.설명으로 다시 미루어 봤을때 이 모든것은 오로지 JS 만을 위해 동작하는 것이므로, 허튼곳에 쓰는 불필요함을 범하지 않도록 하자!!!! (예를들어, 단순히 ts 파일에 타입 공급을 위해 .d.ts를 만든다던지 등등.. 이때는 단순히 ts 안에서 type 를 만들면 되는 부분.)
여기에 아주 완벽한 알고리즘으로 설명돼있다. 다만, @types 관련 부분에서는, tsconfig.json 의 compilerOptions.typeRoots 에 따라 달라질것을 감안해야 할 것이다.
이 알고리즘대로 방문한 결과 패키지(모듈)에 대한 .d.ts 파일이 존재하지 않는다면? 그 때 에러가 발생한다. 이 때는 내 프로젝트에 .d.ts 로 모듈에 대한 타입정의를 커스텀으로 해야한다.
tsconfig.json 에서 include 에 정의된 영역 아무데나 2.전역선언 파일을 만드는것이 간편하고도 일반적인 방법이긴 하다(declare module 이용). 하지만 나는 Resolution 알고리즘을 최대한 활용하여 TS답게 구성해보고 싶다.
그 방법은 tsconfig.json 에서 compilerOptions.typeRoots 에 node_modules/@types 에 더해 내 프로젝트의 커스텀 모듈 타입 경로를 적어주는것. 이렇게 하면 declare 방법 없이 알고리즘을 유지하면서 내가 커스텀으로 좀더 모듈다운 타입정의가 가능할 것으로 기대된다.
그럼에도 불구하고 declare 방법을 사용해야되긴 할거다.. 만약 TS Loader 가 이미지나 json 등의 간단한 것을 인식 못하는 프로젝트인 경우?? 이건 파일명이 와일드카드로 돼있기도 하고 아주 짧은 코드이기 때문에 declare 로 선언하는게 이득이다. 모듈 역시 간단한 정의만 필요하다면 이 방법이 유리하다.
위에서 다룬 .d.ts 가 필요없는 경우는, .ts 파일로 코드를 구성했을 경우. 그 파일 안에서 타입을 좀 더 자유롭게 적어나갈 수 있다.
타입을 한군데 모여서 관리해야 할까? 난 아니라고 생각한다. mvvm 같은 패턴으로 최대한 역할 분리해서 그 코드 내에서 관리하는것이 맞다고 생각한다. 만약 그렇지 않은 상태로 어울리지 않는 모듈 내에 타입이 정의돼 있다면, 그건 모듈을 잘못 분리한 것이 아닐까??