TypeScript Handbook의 Namespaces and Modules를 번역했다.

용어에 대한 노트: 타입스크립트 1.5에서 기록해둘 만큼 중요한 명명법 변경이 있었습니다. “내부 모듈(Internal modules)”은 “네임스페이스”가 되었습니다. “외부 모듈(External modules)”은 이제 간단하게 “모듈(modules)”이 되어 ECMAScript 2015의 용어와 맞췄습니다. (module X {는 namespace X {와 동일하며 후자가 선호됩니다.)

개요

이 포스트는 타입스크립트에서 네임스페이스와 모듈을 사용해 코드를 조직하는 여러가지 방법을 설명합니다. 그리고 어떻게 네임스페이스와 모듈을 사용하고 일반적으로 겪을 수 있는 위험성에는 어떤 부분이 있는지 깊이 있는 주제도 살펴봅니다.

모듈에 대해 더 알고 싶다면 모듈 문서를 참고하세요. 네임스페이스에 대해 더 알고 싶다면 네임스페이스 문서를 참고하세요.

네임스페이스 사용하기

네임스페이스는 단순히 전역 네임스페이스에서의 자바스크립트 개체에 붙은 명칭입니다. 그래서 네임스페이스를 아주 단순한 구조로 사용할 수 있습니다. 여러 파일로 확장해서 작성할 수 있지만 --outFile로 합치는 것도 가능합니다. 네임스페이스는 웹 애플리케이션에서 코드를 구조화하기 좋은 방법이며 HTML 페이지 내에 모든 의존성이 <script> 태그로 포함됩니다.

이 접근 방법은 전역 네임스페이스 오염이 발생하기 때문에 특히 대형 어플리케이션의 경우는 컴포넌트의 의존성을 파악하기 쉽지 않습니다.

모듈 사용하기

모듈도 네임스페이스와 같이 코드와 선언을 모두 포함합니다. 주된 차이점은 모듈은 의존성을 _선언_한다는 점입니다.

또한 모듈은 의존성을 모듈 로더(module loader)를 통해 처리합니다. (예로 CommonJs/Require.js) 작은 크기의 JS 애플리케이션에서는 최적이라고 보기 어렵지만 대형 애플리케이션에서는 장기적인 관점에서 모듈성(modularity)과 유지 가능성(maintainability)에서 이득이 있습니다.

모듈은 코드를 더 쉽게 재사용할 수 있고 더 강하게 고립되어 있으며 번들링을 위해 더 나은 도구를 지원합니다.

Node.js 애플리케이션에서는 모듈을 사용하는 것이 기본적인 방법이며 코드를 구조화하는데 추천되는 접근 방식입니다.

ECMAScript 2015를 사용하면 모듈은 언어에서 제공하는 기능이며 호환 엔진 구현에서는 다 지원해야 합니다. 그러므로 새 프로젝트에서는 코드를 조직하는 방법으로 모듈을 사용하는 것을 추천합니다.

네임스페이스와 모듈의 위험성

여기서는 네임스페이스와 모듈을 사용했을 때 일반적으로 나타나는 다양한 위험에 대해 살펴보고 어떻게 피하는지 확인합니다.

/// <reference>를 사용한 모듈

모듈에서 import 문 대신에 /// <reference ... /> 문법을 사용하는 것이 가장 일반적인 실수입니다. 이 차이를 이해하려면 컴파일러가 import를 사용했을 떄 모듈을 위한 타입 정보를 어디서 가져오는지 이해해야 합니다. (예를 들면 import x from "..."; 또는 import x = require("...");에서의 "...".)

컴파일러는 .ts, .tsx를 먼저 찾은 후에 적절한 경로에 있는 .d.ts를 찾습니다. 특정 파일을 찾지 못한 경우 컴파일러는 _구현 없는 모듈 선언(ambient module declaration)_를 찾습니다. 이런 경우에는 .d.ts의 경로를 선언할 필요가 있습니다.

역자 주: ambient는 주변이란 의미인데 이 이슈의 설명을 기준으로 의역했습니다.

// myModules.d.ts
// .d.ts 파일 또는 모듈이 아닌 .ts 파일
declare module "SomeModule" {
  export function fn(): string;
}

// myOtherModule.ts
/// <reference path="myModules.d.ts" />
import * as m from "SomeModule";

reference 태그는 정의 없는 모듈의 선언에 필요한 선언 파일 위치를 지정할 수 있습니다.

이런 방법으로 여러 타입스크립트 예제에서 node.d.ts을 사용하는 것을 확인할 수 있습니다.

불필요한 네임스페이스

네임스페이스를 사용하는 프로그램을 모듈로 변경한다면 다음과 같은 형태가 되기 쉽습니다.

// shapes.ts
export namespace Shapes {
  export class Triangle { /* ... */ }
  export class Square { /* ... */ }
}

최상위 모듈을 Shapes로 두고 Triangle과 Square를 감쌌는데 이런 방식을 사용할 이유가 없습니다. 이 모듈을 사용하는 입장에서는 혼란스럽고 짜증나는 방식입니다.

// shapeConsumer.ts
import * as shapes from "./shapes";
let t = new shapes.Shapes.Triangle(); // shapes.Shapes?

타입스크립트에서 모듈의 가장 중요한 기능은 다른 두 모듈이라면 절대 동일한 스코프에서 같은 명칭을 사용하지 않는다는 점입니다. 모듈을 사용할 때 직접 명칭에 배정하기 때문에 네임스페이스에서 심볼을 내보내며 일일이 감쌀 필요가 없기 때문입니다.

왜 모듈 내에서 네임스페이스를 사용할 필요가 없는지 고민하게 될지도 모르겠습니다. 네임스페이스는 일반적으로 구조의 논리적인 구분을 제공하고 명칭 충돌을 예방하기 위해 존재하는 개념입니다. 이미 모듈은 논리적으로 구분되어 있고 최상위 명칭은 코드를 불러오는 쪽에서 지정하기 때문에 개체를 내보내기 위해서 추가적인 모듈 계층을 더할 필요가 없는 것입니다.

이런 관점에서 작성한 예제는 다음과 같습니다.

// shapes.ts
export class Triangle { /* ... */ }
export class Square { /* ... */ }

// shapeConsumer.ts
import * as shapes from "./shapes";
let t = new shapes.Triangle();

모듈 사용의 트레이드오프

JS 파일과 모듈이 일대일 대응을 하는 것처럼 타입스크립트도 모듈 소스 파일과 생성된 JS 파일이 일대일로 대응합니다. 이 방식은 어떤 모듈 시스템을 사용하느냐에 따라서 여러 모듈 소스 파일을 합치는 작업이 불가능 할 수 있습니다. outFile 옵션을 commonjs 또는 umd인 경우 외에는 사용할 수 없습니다. 타입스크립트 1.8 이후 버전이라면 amd 또는 system에서도 사용 가능합니다.