타입스크립트(TypeScript)가 뭔가요? 자바스크립트(JavaScript) 개발자를 위한 간단 소개

타입스크립트(TypeScript)가 뭔가요? 자바스크립트(JavaScript) 개발자를 위한 간단 소개

혹시 자바스크립트(JavaScript)는 좀 다뤄봤는데, 타입스크립트(TypeScript)는 어떤 느낌일지 궁금하신가요?

그렇다면 이 글이 딱인데요.

(더 자세히 배우기 전에, '아~ 이런 거구나' 하고 감을 잡는 첫 단계라고 생각하시면 좋습니다.) 이 글을 읽으시면 아래 질문들에 대한 답을 얻으실 수 있습니다.

• 타입스크립트(TypeScript) 코드는 자바스크립트(JavaScript) 코드와 어떻게 다른가요?
• 타입스크립트(TypeScript) 코드는 어떻게 실행되나요?
• 타입스크립트(TypeScript)는 IDE(통합 개발 환경)에서 코드를 편집할 때 어떻게 도움이 되나요?
• 기타 등등...

잠깐! 이 글은 타입스크립트(TypeScript)가 '왜' 좋은지에 대한 설명은 아닙니다.

그게 궁금하시다면, 제가 쓴 타입스크립트(TypeScript) 영업(?) 글을 한번 읽어보시는 것도 좋은데요.

1. 타입스크립트(TypeScript)는 자바스크립트(JavaScript)에 '타입(Type) 문법'을 더한 것!

타입스크립트(TypeScript)를 설명할 때, 100% 정확하다고는 할 수 없지만(몇 가지 예외는 있습니다), 이게 어떻게 돌아가는지 이해하는 데는 이 설명이 꽤 도움이 되는데요.

바로 "타입스크립트(TypeScript)는 자바스크립트(JavaScript)에 타입(Type)을 위한 특별한 문법(Type Syntax)을 더한 것이다" 입니다.

아래 타입스크립트(TypeScript) 코드를 한번 볼까요?

function add(x: number, y: number): number {
  return x + y;
}

 

자바스크립트(JavaScript)랑 비슷해 보이지만, x: number, y: number, : number 같이 생긴 부분이 좀 낯설죠?

이게 바로 타입스크립트(TypeScript)의 '타입 문법'입니다.

x랑 y는 숫자(number)만 받을 거고, 이 함수는 숫자(number)를 돌려줄 거라는 약속인데요.

이 코드를 실제로 컴퓨터가 알아듣고 실행하게 하려면, 이 '타입 문법' 부분을 싹 제거해서, 자바스크립트 엔진(JavaScript Engine)이 실행할 수 있는 순수한 자바스크립트(JavaScript) 코드로 만들어야 합니다.

function add(x, y) {
  return x + y;
}

 

보시다시피 타입스크립트(TypeScript)의 타입 문법은 쏙 빠졌죠?

이 타입 문법은 코드를 실행할 때는 쓰이지 않고, 오직 코드를 작성하거나 컴파일(Compile, 컴퓨터가 이해하는 언어로 바꾸는 과정)할 때 '타입 검사(Type Checking)'를 위해서만 사용되는데요.

덕분에 우리는 "어?

여기에는 숫자가 들어가야 하는데 문자가 들어왔네?"

같은 실수를 미리 발견할 수 있고, 코드를 짤 때 더 똑똑한 자동 완성(Auto-completion) 기능의 도움을 받을 수 있습니다.

2. 타입스크립트(TypeScript) 코드, 어떻게 실행하나요?

자, 그럼 타입스크립트(TypeScript)로 만든 프로젝트는 어떻게 실행할 수 있을까요?

아래와 같은 구조의 타입스크립트(TypeScript) 프로젝트가 있다고 상상해봅시다.

ts-app/
  tsconfig.json
  src/
    main.ts
    util.ts
    util_test.ts
  test/
    integration_test.ts

• tsconfig.json: 이건 설정 파일인데요. 타입스크립트(TypeScript)에게 우리 코드를 어떻게 타입 검사하고, 어떻게 자바스크립트(JavaScript)로 바꿀지(컴파일할지) 알려주는 지침서 같은 겁니다.
• 나머지 .ts 파일들: 이게 바로 우리가 작성한 타입스크립트(TypeScript) 소스 코드입니다.

이 코드를 실행하는 몇 가지 방법을 알아볼까요?

타입스크립트(TypeScript) 직접 실행하기

요즘에는 노드제이에스(Node.js), 데노(Deno), 번(Bun) 같은 서버 쪽(Server-side) 실행 환경(Runtime) 대부분이 타입스크립트(TypeScript) 코드를 바로 실행할 수 있는 기능을 갖추고 있는데요.

즉, 노드제이에스(Node.js) 버전 23.6.0 이상에서는 아래처럼 바로 실행이 가능합니다.

cd ts-app/
node src/main.ts

 

타입스크립트(TypeScript) 번들링(Bundling)하기

웹 앱(Web App)을 개발할 때는 '번들링(Bundling)'이라는 작업을 흔하게 하는데요.

이건 순수한 자바스크립트(JavaScript) 프로젝트에서도 마찬가지입니다.

번들링은 우리가 만든 앱 코드와 가져다 쓴 라이브러리(Library) 코드 등 여러 자바스크립트(JavaScript) 파일들을 하나(가끔은 몇 개)의 큰 자바스크립트(JavaScript) 파일로 합치는 과정을 말합니다.

이 합쳐진 파일은 보통 HTML 파일에서 불러와서 사용하는데요.

이렇게 하면 몇 가지 좋은 점이 있습니다.

• 예전 HTTP/1 시절에는 한 연결당 파일 하나만 받을 수 있어서 번들링이 필수였지만, 요즘 HTTP/2 환경에서는 이 장점은 크게 중요하지 않습니다.
• 그래도 클라이언트(Client, 웹 브라우저 등)가 파일을 요청하고 처리하는 과정에서 파일 개수만큼 약간의 부담은 여전히 발생합니다. (새 연결을 열지 않더라도 말이죠.)
• 웹 서버 입장에서도 여러 개의 작은 파일을 일일이 보내주는 것보다, 하나로 합쳐진 파일을 보내주는 것이 더 효율적입니다.
• 하나의 큰 파일이 여러 개의 작은 파일보다 압축이 더 잘 됩니다.

대부분의 번들러(Bundler, 번들링을 해주는 도구)들은 타입스크립트(TypeScript)를 직접 지원하거나, 플러그인(Plugin)을 통해 지원하는데요.

즉, 번들러가 만들어준 bundle.js 같은 자바스크립트(JavaScript) 파일을 통해 우리 타입스크립트(TypeScript) 코드를 실행하는 방식입니다.

ts-app/
  tsconfig.json
  src/
    main.ts
    util.ts
    util_test.ts
  test/
    integration_test.ts
  dist/
    bundle.js  <-- 번들러가 생성한 자바스크립트 파일

 

타입스크립트(TypeScript)를 자바스크립트(JavaScript)로 변환(Transpiling)하기

또 다른 방법은 타입스크립트 컴파일러(TypeScript Compiler)인 tsc를 이용해서 우리 타입스크립트(TypeScript) 앱을 자바스크립트(JavaScript)로 컴파일(Compile)하고, 그 결과로 나온 자바스크립트(JavaScript) 코드를 실행하는 건데요.

예전에 서버 쪽 자바스크립트(JavaScript) 실행 환경들이 타입스크립트(TypeScript)를 직접 지원하기 전에는, 서버에서 타입스크립트(TypeScript)를 실행하는 유일한 방법이었습니다.

이렇게 소스 코드를 다른 종류의 소스 코드로 변환하는 것을 '트랜스파일링(Transpiling)'이라고도 부르는데요.

tsconfig.json 설정 파일에 어디에 변환된 자바스크립트(JavaScript) 파일을 저장할지 정할 수 있습니다.

예를 들어 dist/라는 폴더에 저장한다고 해봅시다.

ts-app/
  tsconfig.json
  src/
    main.ts
    util.ts
    util_test.ts
  test/
    integration_test.ts
  dist/  <-- 변환된 자바스크립트 파일 저장 폴더
    src/
      main.js
      util.js
      util_test.js
    test/
      integration_test.js

 

로컬 타입스크립트(TypeScript) 모듈 임포트(Import) 시 파일 확장자

기본적으로 타입스크립트(TypeScript)는 다른 파일(모듈)을 불러올 때(import) 그 파일 경로를 바꾸지 않는데요.

이게 무슨 말이냐면, 타입스크립트(TypeScript)를 자바스크립트(JavaScript)로 변환(Transpiling)한 코드를 실행하려면, 코드 안에서 다른 파일을 불러올 때 확장자를 .js로 써줘야 한다는 겁니다.

// main.ts
import {helperFunc} from './util.js'; // 원래 util.ts였지만 .js로 불러와야 함

 

하지만, 타입스크립트(TypeScript) 설정에서 파일 확장자 .ts를 .js로 알아서 바꿔주도록 할 수도 있습니다(더 자세한 정보).

이렇게 하면 아래처럼 .ts 확장자로 불러오는 코드가 타입스크립트(TypeScript)를 직접 실행할 때도, 자바스크립트(JavaScript)로 변환해서 실행할 때도 모두 잘 작동합니다.

// main.ts
import {helperFunc} from './util.ts'; // 이렇게 써도 변환 시 .js로 바뀜

3. 라이브러리(Library) 패키지(Package)를 npm 레지스트리(Registry)에 올리기

다른 사람들이 가져다 쓸 수 있는 코드 묶음, 즉 라이브러리 패키지(Library Package)를 공유하는 가장 인기 있는 방법은 여전히 npm 레지스트리(npm Registry)인데요.

노드제이에스(Node.js) 같은 환경에서는 타입스크립트(TypeScript)로 앱 패키지(App Package)를 작성하는 것을 지원하지만, 라이브러리 패키지(Library Package)는 자바스크립트(JavaScript) 코드나 타입스크립트(TypeScript) 코드 어디서든 사용할 수 있도록, 자바스크립트(JavaScript) 코드 형태로 배포해야 합니다.

그래서 보통 lib.ts라는 타입스크립트(TypeScript) 라이브러리 파일 하나를 배포할 때는, 타입스크립트(TypeScript)가 이 파일로부터 컴파일해서 만든 다른 파일들을 포함해 총 5개 정도의 파일로 구성되는 경우가 많습니다.

• 필수:
  • lib.js: lib.ts의 자바스크립트(JavaScript) 부분. 실제 실행되는 코드입니다.
  • lib.d.ts: lib.ts의 타입(Type) 부분만 담긴 파일. 타입 정보를 제공합니다.
• 선택 (소스맵, Source Maps): 컴파일된 코드의 위치를 원래 lib.ts 코드의 위치와 연결해주는 지도 같은 건데요.
  • lib.js.map: lib.js를 위한 소스맵입니다.
  • lib.d.ts.map: lib.d.ts를 위한 소스맵입니다.
• lib.ts: 위 두 소스맵이 가리키는 원본 타입스크립트(TypeScript) 파일입니다.

(이게 다 무슨 의미인지는 곧 자세히 설명드릴게요.)

예를 들어, 아래와 같은 라이브러리 패키지(Library Package) 구조를 생각해봅시다.

ts-lib/
  package.json
  tsconfig.json
  src/
    lib.ts
  dist/
    src/
      lib.js
      lib.js.map
      lib.d.ts
      lib.d.ts.map

• package.json: 우리 라이브러리 패키지(Library Package)에 대한 정보를 담고 있는 npm의 설명서입니다. 여기에 적힌 내용 중 일부, 예를 들어 '패키지 익스포트(Package Exports)' 같은 정보는 타입스크립트(TypeScript)에서도 사용되는데요. 다른 사람이 우리 패키지를 임포트(Import)할 때 타입 정보를 어디서 찾아야 할지 알려주는 데 쓰입니다.
• dist/ 폴더 안의 모든 파일: 타입스크립트(TypeScript)가 생성한 파일들입니다. 쉽게 다시 만들 수 있기 때문에 보통 버전 관리 시스템(Version Control System, 예: Git)에는 포함하지 않습니다.
• tsconfig.json만 npm 레지스트리(npm Registry)에 업로드되지 않습니다.

필수: .js와 .d.ts 파일

하나의 타입스크립트(TypeScript) 파일(lib.ts)에 합쳐져 있던 자바스크립트(JavaScript) 코드와 타입(Type) 정보가, 왜 굳이 실행 코드만 있는 lib.js와 타입 정보만 있는 lib.d.ts로 나뉘는지 궁금할 수 있는데요.

이렇게 하는 이유는 바로 라이브러리 패키지(Library Package)를 자바스크립트(JavaScript) 프로젝트에서도, 타입스크립트(TypeScript) 프로젝트에서도 모두 사용할 수 있게 하기 위해서입니다.

• 자바스크립트(JavaScript) 코드는 .d.ts 파일(타입 선언 파일)을 몰라도 됩니다. 그냥 무시하고 lib.js만 사용하면 되죠.
• 타입스크립트(TypeScript)는 이 .d.ts 파일을 이용해서 타입 검사(Type Checking)를 하고, 똑똑한 자동 완성(Auto-completion) 기능을 제공하며, 코드에 대한 설명(Documentation)도 보여줍니다.

사실, 우리가 모르는 사이에 비주얼 스튜디오 코드(Visual Studio Code) 같은 많은 코드 편집기(Editor)들은 자바스크립트(JavaScript) 코드를 편집할 때도, 마치 가벼운 타입스크립트(TypeScript) 모드처럼 작동해서 간단한 타입 검사나 코드 완성 기능을 제공하기도 하는데요.

이때 .d.ts 파일이 큰 역할을 합니다.

자, 원래 타입스크립트(TypeScript) 입력 파일인 lib.ts는 이렇게 생겼습니다.

/** 두 숫자를 더합니다. */
export function add(x: number, y: number): number {
  return x + y; // 숫자 덧셈
}

 

이게 컴파일되면, 한편으로는 자바스크립트(JavaScript) 코드만 남은 lib.js가 됩니다.

/** 두 숫자를 더합니다. */
export function add(x, y) {
    return x + y; // 숫자 덧셈
}
//# sourceMappingURL=lib.js.map

 

다른 한편으로는, 타입 정보만 담긴 lib.d.ts 파일이 됩니다.

/** 두 숫자를 더합니다. */
export declare function add(x: number, y: number): number;
//# sourceMappingURL=lib.d.ts.map

 

참고:

• 두 파일 모두 맨 아래에 각자의 소스맵(Source Map) 파일을 가리키는 주석이 있습니다.
• 기본적으로 두 파일 모두 주석을 포함하는데요. (설정을 통해 포함하지 않게 할 수도 있습니다.)
  • lib.js: 코드 가독성을 위해 모든 주석을 포함합니다.
  • lib.d.ts: /** */ 형태의 제이에스독(JSDoc) 주석만 포함합니다. 많은 IDE(통합 개발 환경)가 이 주석을 사용해서 코드에 대한 설명을 바로 보여주기 때문입니다.

 

선택: 소스맵(Source Maps)

만약 우리가 I라는 원본 파일을 컴파일해서 O라는 결과 파일을 만들었다면, O를 위한 소스맵(Source Map)은 O 파일의 특정 위치가 원본 I 파일의 어떤 위치에 해당하는지를 알려주는 지도 같은 건데요.

이게 있으면 우리는 컴파일된 O 파일을 가지고 작업하면서도, 원본 I 파일의 정보를 볼 수 있습니다.

예를 들면,

• lib.js.map: lib.js 파일의 위치를 lib.ts 파일의 위치로 연결해줍니다. 덕분에 우리는 lib.js를 실행하면서도, 오류가 발생했을 때 원본 lib.ts 코드의 어느 부분에서 문제가 생겼는지(스택 트레이스, Stack Trace) 보거나, 디버깅(Debugging)을 할 때도 원본 코드를 기준으로 할 수 있습니다.
• lib.d.ts.map: lib.d.ts 파일의 각 줄을 lib.ts 파일의 줄과 연결해줍니다. 덕분에 라이브러리에서 임포트(Import)한 함수의 '정의로 이동(Go to Definition)' 같은 기능을 사용했을 때, .d.ts 파일이 아닌 원본 lib.ts 파일로 바로 이동할 수 있게 해줍니다.

스택 트레이스(Stack Trace)를 제외한 대부분의 소스맵 관련 기능은 원본 타입스크립트(TypeScript) 소스 코드에 접근할 수 있어야 제대로 작동하는데요.

그래서 소스맵을 포함할 거라면, 원본 lib.ts 파일도 함께 배포하는 것이 좋습니다.

lib.js.map 파일은 대략 이렇게 생겼습니다 (실제 내용은 더 깁니다).

{
  "version": 3,
  "file": "lib.js",
  "sourceRoot": "",
  "sources": [
    "../../src/lib.ts"
  ],
  "names": [],
  "mappings": "AAAA,uBAAuB;AACvB,MAAM,UAAU,···"
}

 

lib.d.ts.map 파일은 이렇게 생겼구요.

{
  "version": 3,
  "file": "lib.d.ts",
  "sourceRoot": "",
  "sources": [
    "../../src/lib.ts"
  ],
  "names": [],
  "mappings": "AAAA,uBAAuB;AACvB,wBAAgB,GAAG,···"
}

 

두 경우 모두 실제 "mappings" 부분의 내용은 훨씬 길지만 줄여서 표시했는데요.

실제 tsc가 만드는 결과물에서는 JSON이 한 줄로 압축되어 있습니다.

 

데피니틀리타입트(DefinitelyTyped): 타입(Type) 없는 npm 패키지(Package)를 위한 타입 저장소

요즘에는 많은 npm 패키지(Package)들이 자체적으로 타입스크립트(TypeScript) 타입(.d.ts 파일)을 포함해서 나오는데요.

하지만 아직 그렇지 않은 패키지들도 있습니다.

그럴 때 도움이 될 수 있는 곳이 바로 데피니틀리타입트(DefinitelyTyped)라는 곳입니다.

만약 타입이 없는 pkg라는 패키지를 사용하고 싶은데, 데피니틀리타입트(DefinitelyTyped)에 이 패키지를 위한 타입이 있다면, 우리는 @types/pkg라는 별도의 패키지를 추가로 설치해서 pkg 패키지의 타입 정보를 얻을 수 있습니다.

노드제이에스(Node.js) 개발에서 아주 중요한 데피니틀리타입트(DefinitelyTyped) 패키지 중 하나는 @types/node인데요.

여기에는 노드제이에스(Node.js)의 모든 API에 대한 타입 정보가 들어있습니다.

노드제이에스(Node.js) 환경에서 타입스크립트(TypeScript)로 개발한다면, 거의 항상 이 패키지를 개발 의존성(Development Dependency)으로 설치하게 될 겁니다.

 

tsc 외 다른 도구로 타입스크립트(TypeScript) 컴파일하기

tsc (타입스크립트 컴파일러)가 하는 일들을 다시 한번 정리해볼까요?

(여기서는 소스맵은 잠시 잊겠습니다.)

1. 타입스크립트(TypeScript) 파일을 자바스크립트(JavaScript) 파일로 컴파일합니다.
2. 타입스크립트(TypeScript) 파일을 타입 선언 파일(.d.ts)로 컴파일합니다.
3. 타입스크립트(TypeScript) 파일을 타입 검사합니다.

이 중에서 3번, 타입 검사는 매우 복잡한 작업이라서 오직 tsc만이 제대로 할 수 있는데요.

하지만 1번과 2번 작업은, 타입스크립트(TypeScript)의 모든 기능을 다 쓰지 않고, 문법적인 처리만으로도 충분히 가능한, 약간 더 단순한 범위의 타입스크립트(TypeScript)에 대해서는 tsc보다 훨씬 빠른 다른 도구들을 사용할 수도 있습니다.

심지어 tsconfig.json 설정에는 우리가 이런 '단순한 범위의 타입스크립트(TypeScript)'를 벗어나지 않도록 경고해주는 옵션들도 있습니다(더 자세한 정보).

실제로 이렇게 제약을 두는 것이 크게 불편하지 않은 경우가 많습니다.

 

타입 제거(Type Stripping)

타입스크립트(TypeScript)를 자바스크립트(JavaScript)로 컴파일하는 가장 간단한 방법은 '타입 제거(Type Stripping)'인데요.

• 컴파일 과정이 단순히 타입 문법(Type Syntax)을 제거하는 것으로만 이루어집니다.
• 언어 수준의 기능을 변환(Transpiling)하지 않습니다.

두 번째 특징 때문에, 몇몇 타입스크립트(TypeScript) 기능은 이 방식에서 지원되지 않는데요.

예를 들면 다음과 같습니다.

• JSX (리액트(React) 등에서 사용하는, 타입스크립트(TypeScript) 안에 HTML 비슷한 문법을 쓰는 것)
• 이넘(Enums)
• 클래스(Class) 생성자(Constructor)의 매개변수 속성(Parameter Properties)
• 네임스페이스(Namespaces)
• 미래의 자바스크립트(JavaScript) 문법을 현재의 자바스크립트(JavaScript)로 변환하는 것

타입 제거(Type Stripping) 방식의 상당한 장점 중 하나는, 매우 간단하기 때문에 tsconfig.json 같은 별도의 설정이 거의 필요 없다는 점인데요.

이 방식를 사용하는 플랫폼(Platform)들은 타입스크립트(TypeScript) 자체의 변화에 덜 영향을 받고 더 안정적일 수 있습니다.

타입 제거(Type Stripping) 기법: 타입을 공백으로 바꾸기

타입 제거(Type Stripping)를 위한 아주 똑똑한 기법 중 하나는 ts-blank-space라는 도구(블룸버그(Bloomberg)의 애슐리 클레이모어(Ashley Claymore) 개발)가 처음 선보였는데요.

타입 문법을 그냥 삭제하는 대신, 그 자리를 공백(Space)으로 바꿔치기하는 겁니다.

이렇게 하면, 결과로 나온 자바스크립트(JavaScript) 코드의 줄 번호나 칸 번호가 원본 타입스크립트(TypeScript) 코드와 거의 변하지 않게 되는데요.

덕분에 오류가 발생했을 때 스택 트레이스(Stack Trace)에 나오는 위치 정보가 원본 코드에도 그대로 적용될 수 있어서, 소스맵(Source Map)의 필요성이 줄어듭니다.

물론 디버깅(Debugging)이나 정의로 이동(Go to Definition) 같은 기능을 위해서는 여전히 소스맵이 필요하겠지만, 타입 제거(Type Stripping)로 생성된 자바스크립트(JavaScript)는 원본 타입스크립트(TypeScript)와 꽤 비슷해서, 소스맵 없이도 괜찮을 때가 많습니다.

예를 들어, 입력 (타입스크립트(TypeScript)):

function add(x: number, y: number): number {
  return x + y;
}

 

출력 (자바스크립트(JavaScript), 공백으로 대체):

function add(x        , y        )         {
  return x + y;
}

 

타입 문법이 있던 자리가 공백으로 채워진 게 보이시죠?

더 궁금하시면, ts-blank-space 플레이그라운드(Playground)에서 직접 실험해볼 수 있습니다.

 

고립된 선언(Isolated Declarations)

'고립된 선언(Isolated Declaration)'은 타입스크립트(TypeScript)를 작성하는 하나의 스타일인데요.

.d.ts (타입 선언 파일)을 쉽게 추출할 수 있도록 코드를 작성하는 방식입니다.

주로 외부로 내보내는(export) 함수의 반환 타입(Return Type)을 명시적으로 적어주는 것을 의미하는데요.

원칙적으로 타입스크립트(TypeScript)는 우리가 반환 타입을 적지 않아도 알아서 추론해낼 수 있지만, 간단한 선언 파일 생성 도구들은 그렇게 하지 못할 수 있습니다.

이 제약은 외부로 내보내지 않는(unexported) 함수에는 적용되지 않는데요.

왜냐하면 그런 함수들은 선언 파일에 포함되지 않기 때문입니다.

타입스크립트(TypeScript) 파일 strings.ts의 첫 번째 버전:

// 안 좋아요: 외부로 내보내는 함수인데 반환 타입이 없음
export function upperCase(str: string) {
  return str.toUpperCase();
}

// 내보내지 않으므로 반환 타입 없어도 됨
function internalHelper() {}

 

고립된 선언(Isolated Declaration) 스타일로 작성한 strings.ts:

// 좋아요: 외부로 내보내는 함수에 반환 타입 명시
export function upperCase(str: string): string {
  return str.toUpperCase();
}

// 내보내지 않으므로 반환 타입 없어도 됨
function internalHelper() {}

 

이렇게 작성하면, 생성되는 선언 파일 strings.d.ts는 다음과 같습니다 (internalHelper는 포함되지 않은 것을 확인하세요):

export declare function upperCase(str: string): string;

 

 

JSR – 자바스크립트 레지스트리(JavaScript Registry)

자바스크립트 레지스트리(JavaScript Registry, JSR)는 패키지(Package)를 배포하는 데 있어 npm 및 npm 레지스트리(npm Registry)의 대안으로 등장한 곳인데요.

작동 방식은 다음과 같습니다.

• 타입스크립트(TypeScript) 패키지(Package)의 경우, .ts 파일만 업로드합니다.
• 타입스크립트(TypeScript) 패키지(Package)를 설치하는 방법은 플랫폼(Platform)에 따라 다른데요.
  • 타입스크립트(TypeScript) 전용 라이브러리 패키지(Library Package)를 지원하는 자바스크립트(JavaScript) 플랫폼에서는, JSR이 타입스크립트(TypeScript) 파일만 설치합니다.
  • 다른 모든 플랫폼에서는, JSR이 자동으로 .js 파일과 .d.ts 파일을 생성해서, 원본 .ts 파일과 함께 설치해줍니다. 이렇게 자동으로 생성하려면, 타입스크립트(TypeScript) 코드가 '느린 타입 없음(no slow types)'이라는 규칙을 따라야 하는데요. 이건 앞서 본 고립된 선언(Isolated Declarations)과 비슷합니다.

반면에, npm 레지스트리(npm Registry)를 사용하면, 여러분의 타입스크립트(TypeScript) 라이브러리 패키지(Library Package)는 .js 파일과 .d.ts 파일을 직접 업로드해야만 노드제이에스(Node.js) 같은 환경에서 사용할 수 있습니다.

JSR은 또한 문서 자동 생성과 같이 npm에는 없는 여러 기능들을 제공하는데요.

더 자세한 정보는 공식 문서의 "Why JSR?"

부분을 참고하시면 좋습니다.

 

JSR은 누가 운영하나요?

공식 문서의 "거버넌스(Governance)" 페이지를 인용하면 이렇습니다:

JSR은 특정 개인이나 조직이 소유하지 않습니다.

이는 모든 사람에게 열려 있고, 전체 자바스크립트(JavaScript) 생태계를 위해 구축된 커뮤니티 주도 프로젝트입니다.

JSR은 현재 데노(Deno) 회사에서 운영하고 있습니다.

우리는 현재 프로젝트를 감독할 거버넌스 위원회를 설립하기 위해 노력하고 있으며, 이후 프로젝트를 재단으로 이전하는 작업을 진행할 것입니다.

4. 타입스크립트(TypeScript) 편집하기

자바스크립트(JavaScript)를 위한 인기 있는 IDE(통합 개발 환경) 두 가지를 꼽으라면 다음과 같습니다.

• 비주얼 스튜디오 코드(Visual Studio Code) (무료)
• 웹스톰(WebStorm) (비상업적 용도로는 무료)

여기서 설명할 내용은 비주얼 스튜디오 코드(Visual Studio Code)를 기준으로 하지만, 다른 IDE(통합 개발 환경)에도 적용될 수 있습니다.

비주얼 스튜디오 코드(Visual Studio Code)를 사용하면, 타입 검사(Type Checking)를 두 가지 다른 방식으로 할 수 있는데요.

• 현재 편집기에서 열려 있는 파일은 비주얼 스튜디오 코드(Visual Studio Code) 내에서 자동으로 타입 검사가 이루어집니다. 이 기능을 제공하기 위해, 비주얼 스튜디오 코드(Visual Studio Code)는 자체적으로 타입스크립트(TypeScript)를 내장하고 있습니다.
• 만약 프로젝트 전체의 모든 코드에 대해 타입 검사를 하고 싶다면, 타입스크립트 컴파일러(TypeScript Compiler) tsc를 직접 실행해야 하는데요. 비주얼 스튜디오 코드(Visual Studio Code)의 '작업(Tasks)' 기능을 통해 할 수 있습니다. 이 기능은 타입 검사, 컴파일, 번들링 등 외부 도구를 실행하는 내장된 방법입니다. 작업(Tasks)에 대한 더 자세한 내용은 공식 문서에 잘 나와 있습니다.

 

자바스크립트(JavaScript) 파일 타입 검사하기

선택적으로, 타입스크립트(TypeScript)는 자바스크립트(JavaScript) 파일도 타입 검사를 할 수 있습니다.

물론, 타입 정보가 없는 자바스크립트(JavaScript) 파일만으로는 얻을 수 있는 결과에 한계가 있는데요.

하지만, 타입스크립트(TypeScript)를 돕기 위해, 우리는 제이에스독(JSDoc) 주석을 사용해서 타입 정보를 추가할 수 있습니다.

예를 들면 이렇습니다.

/**
 * @param {number} x - 첫 번째 피연산자
 * @param {number} y - 두 번째 피연산자
 * @returns {number} 두 피연산자의 합
 */
function add(x, y) {
  return x + y;
}

 

이렇게 하면, 우리는 여전히 타입스크립트(TypeScript)를 작성하고 있는 셈인데요.

단지 문법이 다를 뿐입니다.

이 방식의 장점은 다음과 같습니다.

• 타입스크립트(TypeScript)를 지원하지 않는 환경(예: 브라우저)에서도 코드를 실행하기 위해 별도의 빌드(Build) 과정이 필요 없습니다.
• 제이에스독(JSDoc) 주석이 있는 .js 파일로부터 .d.ts 파일(타입 선언 파일)을 생성할 수도 있습니다. (물론 이건 추가적인 빌드 단계가 필요합니다.) 이 방법은 타입스크립트 핸드북(TypeScript Handbook)에 설명되어 있습니다.
• 기존의 자바스크립트(JavaScript) 코드 베이스를 점진적으로, 조금씩 더 타입에 안전하게(Type-safe) 만들 수 있게 해줍니다.

이 방식의 단점은 다음과 같습니다.

• 문법이 사용하기에 덜 깔끔해집니다.

단점을 설명하기 위해, 타입스크립트(TypeScript)에서 인터페이스(Interface)를 정의하는 방법을 봅시다.

interface Point {
  x: number;
  y: number;
  /** 선택적 속성 */
  z?: number;
}

 

이것을 제이에스독(JSDoc) 주석으로 하려면 이렇게 보이는데요.

/**
 * @typedef Point
 * @prop {number} x
 * @prop {number} y
 * @prop {number} [z] 선택적 속성
 */

 

확실히 타입스크립트(TypeScript) 문법이 더 간결하죠?

---