TypeScript의 고유한 개념 중 일부는 타입 레벨에서 JavaScript 객체의 형태를 설명합니다.

특히 TypeScript에서의 고유한 예로는 '선언 병합'이라는 개념이 있습니다.

이 개념을 이해하는 것은 기존 JavaScript를 사용할 때 이점을 제공할 것입니다.

또한 고급 추상화 개념에 대한 문을 열어줍니다.

TypeScript에서 선언은 다음 세 가지 중 하나 이상의 엔티티를 생성합니다: 네임스페이스, 타입 또는 값

네임스페이스-생성 선언은 점 표기법을 사용하여 접근하는 이름이 포함된 네임스페이스를 생성합니다.

타입-생성 선언은 다음과 같습니다: 선언된 형태로 표시되고 주어진 이름에 바인딩 되는 타입을 작성합니다.

마지막으로, 값-생성 선언은 출력된 JavaScript에서 볼 수 있는 값을 만듭니다.

| 선언 타입 | 네임스페이스 | 타입 | 값 |

|---------------|:------------:|:----:|:----:|

| 네임스페이스 | X | | X |

| 클래스 | | X | X |

| 열거형 | | X | X |

| 인터페이스 | | X | |

| 타입 별칭 | | X | |

| 함수 | | | X |

| 변수 | | | X |

각 선언으로 생성된 내용을 이해하면 선언 병합을 수행할 때 병합되는 내용을 이해하는 데 도움이 됩니다.

가장 단순하고 아마도 가장 일반적인 타입의 선언 병합은 인터페이스 병합입니다.

가장 기본적인 수준에서 이 병합은 두 선언의 멤버를 기계적으로 같은 이름의 단일 인터페이스에 결합합니다.

interface Box {

let box: Box = {height: 5, width: 6, scale: 10};

인터페이스의 비-함수 멤버는 고유해야 합니다.

고유하지 않다면 같은 타입이어야 합니다.

컴파일러는 인터페이스가 모두 같은 이름이지만 다른 타입의 비-함수 멤버를 선언하는 경우 오류를 발생시킵니다.

함수 멤버의 경우 같은 이름의 각 함수 멤버가 같은 함수의 오버로드를 설명하는 것으로 간주합니다.

또한 후위의 인터페이스 `A`와 인터페이스 `A`를 병합하는 경우에는 두 번째 인터페이스가 첫 번째 인터페이스보다 우선순위가 더 높다는 점이 주목됩니다.

예를 들어 다음과 같습니다:

}

각 그룹의 요소는 같은 순서를 유지하지만 그룹 자체는 나중에 오버로드가 발생한 것이 가장 먼저 병합됩니다.

이 규칙에 대한 한가지 예외는 특수한 서명(specialized signatures)입니다.

서명의 타입이 *단일* 문자열 리터럴 타입(예 : 문자열 리터럴의 유니온이 아닌)인 매개 변수가 있는 경우 병합된 오버로드 목록의 맨 위로 버블링됩니다.

예를 들어 TypeScript 컴파일러는 한쪽에는 타입이 있지만 다른 한쪽에 타입이 없는 경우 그 타입을 이해할 수 없다는 것을 알게 됩니다:

`function pickCard (x) : any` 조각은 오버로드 목록의 일부가 아니므로 두 개의 오버로드만 있습니다:

하나는 객체를 취하고 하나는 숫자를 취합니다.

}

`loggingIdentity` 는 타입 매개 변수 `T` 를 인수로 받고 `arg` 는 `T` 배열이며 `T` 배열을 반환합니다. 숫자 배열을 인수로 넘기면 `T` 가 `number` 에 바인딩 되기 때문에 숫자 배열을 반환할 것입니다. 이렇게하면 모든 타입이 아닌 처리하고자 하는 타입의 일부로 제네릭 타입 변수 `T` 를 사용하여 유연성을 높일 수 있습니다.

혹은 다음 예제와 같이 작성할 수 있습니다.

그러나 non-relative 모듈 imports의 경우 컴파일러는 imports 파일이 포함된 디렉토리부터 시작하여 일치하는 정의 파일을 가져오기 위해 디렉토리 트리를 찾으려합니다.

예를 들어:

`moduleB`를 소스 파일에서 `import { b } from "moduleB"`와 같이 상대적으로 가져오지 않으면 `"moduleB"`를 찾기 위해 다음과 같은 위치에서 찾게 됩니다:

Node.js는 `--module commonjs`를 사용하세요.

require.js의 경우 --module amd를 사용합니다.

예를 들어:

tsc --module commonjs Test.ts

각 모듈을 `.d.ts` 파일에 최상위 수준의 내보내기 선언으로 정의할 수 있지만 더 넓은 `.d.ts` 파일로 작성하는 것이 더 편리합니다.

그렇게하기 위해서 ambient 네임스페이스와 비슷한 구조를 사용하지만 나중에 import 할 수 있는 모듈의 `module` 키워드와 따옴표 붙은 이름을 사용합니다.

예를 들어:

이러한 모듈을 [UMD](https://github.com/umdjs/umd) 모듈이라고 합니다.

이러한 라이브러리는 import 또는 글로벌 변수를 통해 접근할 수 있습니다.

예를 들어:

모듈의 주요 목적이 하나의 특정 export를 저장하는 것이라면 이를 default export로 export 하는 것을 고려해야 합니다.

이렇게 하면 importing를 사용하며 실제로 import를 더 쉽게 사용할 수 있습니다.

예를 들어:

또는 파일별 컴파일(기본값)을 사용하여 각 입력 파일에 대한 JavaScript 파일을 하나씩 내보낼 수 있습니다.

만약 여러 개의 JS 파일이 생성되면 웹 페이지에 있는 `<script>`태그를 사용하여 출력된 각 파일을 적절한 순서대로 로드해야 합니다.

예를 들어:

- [x] 네임스페이스

- [x] 네임스페이스와 모듈

- [x] 모듈 해석

- [X] 선언 병합

- [X] JSX

- [ ] Introduction

- [ ] Library Structures