마이크로소프트에서 구현한 JavaScript의 슈퍼셋(Superset) 프로그래밍 언어. 확장자로는 .ts를 사용하며, 컴파일의 결과물로 JavaScript 파일인 .js를 출력한다. 최종적으로 런타임에서는 이렇게 출력된 JavaScript 코드를 구동시키게 된다.

TypeScript라는 이름답게 정적 타입을 명시할 수 있다는 것이 순수한 자바스크립트와의 가장 큰 차이점이다. 덕분에 개발 도구(IDE나 컴파일러 등)에게 개발자가 의도한 변수나 함수 등의 목적을 더욱 명확하게 전달할 수 있고, 그렇게 전달된 정보를 기반으로 코드 자동 완성이나 잘못된 변수/함수 사용에 대한 에러 알림[1] 같은 풍부한 피드백을 받을 수 있게 되므로 순수 자바스크립트에 비해 어마어마한 생산성 향상을 꾀할 수 있다. 즉, '자바스크립트를 실제로 사용하기 전에 있을만한 타입 에러들을 미리 잡는 것' 이 타입스크립트의 사용 목적이다.

개발자와 도구 간의 상호작용에서 뿐만 아니라 개발자 간의 상호작용에서도 상당한 이점이 있는데, API를 구현하고 사용함에 있어 해당 API의 인풋과 아웃풋이 무엇인지 명확하게 표현할 수 있으므로, API 하나 쓰는데에도 일일이 매뉴얼을 찾아봐야 하거나 심하면 해당 API의 코드까지 뒤적거려봐야 하는 자바스크립트에 비해 효율적이다.

타입스크립트를 사용하려면 npm이 필요하다. Node.js를 설치하면 npm이 자동으로 설치된다. npm을 설치하고 나면 터미널이나 명령 프롬프트에서

npm i -g typescript

를 입력하면 타입스크립트 컴파일러(타입스크립트 → 자바스크립트 변환기)가 설치된다.

만일 Windows의 파워셸에서 오류가 발생했다면 관리자 권한의 파워셸에서

Set-ExecutionPolicy RemoteSigned

를 통해 파워셸에 권한을 주고 입력한다.

Mac/Linux에서 Node.js와 npm을 사용할 때, 위에서 언급한 Windows환경에서의 권한문제와 유사한 권한 문제가 발생할 수 있다. 그런 문제를 미연에 방지하기 위해 nvm을 먼저 설치하고 npm을 사용하기를 권장한다. nvm을 쓰지 않고 Node.js와 npm을 사용하는건 물론 가능하지만 특히 Mac은 sudo를 웬만하면 사용하지 말라고 하는 OS인 만큼, 정말 정말 정말 귀찮은 문제에 많이 얽힐 수 있으니, 정신건강과 보안을 위해 nvm을 꼭! 설치하기 바란다. Windows에서도 nvm사용은 가능하나 nvm-windows 는 위의 nvm과 완전히 분리된 프로젝트임을 감안하고 사용해야 한다.

그 뒤로는 .ts 파일을 타입스크립트를 사용하여 작성하고 터미널이나 명령 프롬프트에서 해당 폴더로 이동하여 'tsc 파일이름(확장자 제외)'를 입력해주면 된다.

예) 파일 이름이 script.ts 일 때,

tsc script

위와 같이 입력하면 script.js 파일이 같은 폴더에 생성된다.

또는 아래와 같은 방법도 있다 :

tsc --init

를 실행한 후, 생성되는 tsconfig.json을 수정하고 아래와 같은 명령어를 사용해도 동일한 결과가 나온다.

tsc

다양한 IDE들이 타입스크립트를 지원하고 있지만, 역시 타입스크립트의 제작사인 마이크로소프트의 비주얼 스튜디오 코드와의 가장 정합성이 훌륭하다고 평가받고 있다. 위의 커맨드를 내부 터미널에 입력해 컴파일할 수도 있고, 프로젝트 내의 .vscode 폴더에 launch.json및 task.json 설정 파일을 생성해서 본인의 프로젝트에 적합한 설정을 입력해주면 비주얼 스튜디오처럼 F5, 혹은 Ctrl + F5 단축키로 컴파일부터 실행까지 일사천리로 진행시킬 수도 있다.

타입스크립트에서는 버그가 일어나기 쉬운 요소의 타입을 선언하여 버그가 일어나는 것을 막아준다. 가령 자바스크립트에서는 타입이 다른 두 변수를 계산을 시켜주면

const a = 3;
const b = '5';
console.log(a*b)

이게 계산이 작동되어 15를 출력하는 기능이 있다. 만일 프로그래머가 이게 다른 언어처럼 계산이 작동하지 않을 것을 의도하고 이렇게 코드를 지었다면 의도치 않은 작업이 이루어지는 버그가 발생하는 것이다.

타입스크립트에서는

const a:number = 3;
const b:string = '5';
console.log(a*b)

이렇게 숫자면 숫자, 문자열이면 문자열이라고 타입을 선언해주어서 계산이 작동되지 못하게 하거나, 컴파일 전에 오류 메시지를 띄우게 한다.[오류메시지]

var alist = document.querySelectorAll('a');
for (var i = 0; i < alist.length; i++) {
  alist[i].style.color = '#333'
};

var example = document.querySelector('.exampleClass');
example.style.backgroundColor = "#ccc";

document.addEventListener('mousemove', function () {
  var x = event.clientX;
  document.querySelector('h1').style.fontSize = (x / 50) + 'px'
});

const alist = document.querySelectorAll('a');
for (let i: number = 0; i < alist.length; i++) {
  alist[i].style.color = '#333'
};

const example: HTMLElement = document.querySelector('.exampleClass');
example.style.backgroundColor = "#ccc";

document.addEventListener('mousemove', function (event: MouseEvent) {
  const x = event.clientX;
  (document.querySelector('h1') as HTMLElement).style.fontSize = String(x / 50) + 'px';
});

타입스크립트는 Node.js 런타임 뿐만 아니라, 원래 자바스크립트의 고향인 프론트엔드 개발에서도 상당히 유용하다. 특히 프론트엔드와 백엔드[11]를 모두 TypeScript로 구현한다면 종전과는 비교할 수 없을 정도로 높은 개발 안정성과 편의성을 확보할 수 있다. 프론트엔드-백엔드 상호 간 데이터 통신을 위해서는 일반적으로 JSON 형식의 REST API를 구현하게 되는데, [12] 이렇게 사용되는 데이터 포맷은 개발 과정 중에 수없이 변경되고 또 변경되기 마련이다. 이로 인해 프론트엔드와 백엔드 개발자 사이에서는 수도 없이 커뮤니케이션 로스가 발생하고[13] 이는 고스란히 개발자의 피로도 상승 및 개발 기간 증가, 유지보수성의 저하로 이어진다. 게다가 이러한 문제점은 실제로 코드를 동작시키지 전까지는 알아채기 어려운 경우도 많기 때문에 최악의 경우 검증되지 않은 버그가 남은 채 프로젝트를 퍼블리시하게 될 수도 있다. TypeScript가 이러한 사태를 미연에 방지할 수 있는 이유는, 프론트엔드와 백엔드간의 데이터 포맷을 타입으로 정의하여, 이를 양측에서 공통으로 참조하도록 구현하고[14], 데이터 포맷의 변경 사항이 발생할 경우 이렇게 공용화된 타입의 정의부를 수정함에 따라 프론트엔드와 백엔드 코드에 컴파일 에러를 발생시킴으로써 데이터 포맷의 통일을 강제하기 때문이다.[15]

물론 백엔드 개발자들은, 타입스크립트 사용 이전에 프론트엔드 개발자에게 올바른 API를 제공하고 본인의 정신건강을 지키기 위해서는 Swagger등의 API문서의 작성이 선행되는 게 권장되긴 하겠으나, IDE에서 제공하는 자동 완성이나 API 에러 알림 등의 피드백 덕분에 문서 참조의 필요성을 줄일 수 있다는 것 자체가 상당한 장점이다.

물론 프론트엔드에서도 단독으로 사용이 가능하다. 바닐라 자바스크립트로 컴파일 되는 것은 당연하거니와, Google의 Angular프레임워크는 2.0부터 아예 타입스크립트만 사용가능하도록 바뀌었다그 때문에 사용자들이 많이 떨어져나갔지만. Facebook의 리액트는 React.js와 React Native를 가리지 않고 타입스크립트 사용이 가능하다. 현재는 JavaScript와 TypeScript진영간의 교류도 굉장히 활발하고, DefinitelyTyped 등의 기여로부터 React에서 TypeScript를 사용하는 것은 정석 중의 하나로 자리잡았다. React의 경우는 특히나 Functional Component, Hooks와 함께 타입스크립트를 사용한다면 이전에 클래스 컴포넌트를 사용할때보다 훨씬 쉽게 개발이 가능하다.

타입스크립트를 사용할 때, 타입스크립트가 런타임에서 그대로 돌아가는 경우는 드물다. 개요에 서술하였듯 타입스크립트는 컴파일을 통해 자바스크립트로 변환되는 것이 일단 첫번째 목적인데, 그렇기 때문에 기존의 자바스크립트와 함께 사용하는 것이 가능하며, 자바스크립트 런타임은 그 컴파일된 자바스크립트를 기존의 자바스크립트 파일과 실행 가능하게 되는 것이다. 기존의 자바스크립트 프로그래머들은 타입스크립트를 도입할 때, 처음 고려해봐야 할 것이 '*.d.ts' 파일 작성이다. 클래스, 클래스, 또는 어떤 자바스크립트 객체이든지 타입스크립트로 정의 가능한데, 기존의 자바스크립트 소스를 일절 건드리지 않고 *.d.ts 파일 작성만으로 타입스크립트 도입에 큰 도움을 줄 수 있다. DefinitelyTyped 레포지토리에서 다운받는 @types/<패키지이름> 패키지가 그것이다. 이 레포지토리는 기존 자바스크립트 npm 패키지들이 기존 소스를 건드리지 않고 타입스크립트 진영에 자연스럽게 녹아들 수 있도록 도움을 주었다. Javascript 언어 차원에서 지원하는 API들의 입출력 타입들도 친절하게 정의돼 있기 때문에 이를 더 안정적으로 사용할 수 있게 되기도 한다.

또한 타입스크립트는 const, let 같은 ec2015 이상의 버전에서 사용되는 구문을 지원하는데, 이걸 컴파일을 시키게 되면 ec3 버전으로 컴파일을 시켜줘서 IE 구버전에서도 작동할 수 있게 해준다! 즉, 상위 버전의 자바스크립트 구문을 사용하고도 IE 구버전을 지원할 수 있다.

애초에 자바스크립트가 C, C++, 자바나 C#같은 언어들처럼 (), {}, ; 등을 사용하는 C-family언어이기 때문에 문법적으로 유사함을 내세우는 타입스크립트 역시 C-family인데, 그 정도가 특히 더 가까워져서, 예를 들면 Generic에 <> 기호를 쓴다. 타입스크립트가 자바, C#, C++와는 본질적으로 비슷하지도 않지만, 타입스크립트를 처음 입문하는 기존 개발자들은 '어! 저거 제네릭이네!' 라고 빠르게 이해할 수 있을 것이다. 거기에 interface, const 같은 지시문 역시 기존 언어 사용자들이 익숙하다고 느낄만한 사용방법을 갖고 있다.

타입 개념의 도입을 통해 TypeScript 개발을 지원하는 IDE로부터 풍부한 피드백을 받을 수 있다. 일반적인 여느 정적 타입 언어들처럼 자동 완성을 지원하거나, 해당 타입이 지원하지 않는 연산[16]의 시도나 잘못된 인자를 사용한 함수 호출 등을 코딩 중에 즉석에서 검출할 수 있는 것은 기본. 심볼의 이름을 변경하면 해당 심볼을 참조하는 모든 코드들을 자동으로 수정해주는 리팩토링 기능 역시 JavaScript가 아닌 TypeScript이기 때문에 지원될 수 있는 기능이다. 대표적인 IDE로는 JetBrains의 WebStorm이 있으며 IntelliJ IDEA도 얼티밋 에디션을 구입하면 웹 개발 기능을 사용할 수 있다.

특히 Microsoft에서 만든 언어답게, 같은 회사에서 만든 Visual Studio Code(이하 VSC)와의 궁합이 엄청나다. IDE는 아니지만, 각종 플러그인을 통해 TypeScript로 상상할 수 있는 모든 개발환경을 너무나 쉽게 구축 가능하다. VSC나 그 플러그인 역시 대부분 TypeScript로 개발되고 있기 때문에 당연하다면 당연한 결과.

뿌리가 자바스크립트인만큼 Node.js의 npm 패키지들을 손쉽게 사용할 수 있으며, 타입스크립트 컴파일러 자체가 npm 패키지이기도 하다. npm install typescript로 설치 가능하다.

타입스크립트는 결국 자바스크립트로 컴파일되어 동작하고, 이는 역시 '런타임에는 약타입' 이라는 약점이 있다. 예를 들면, 타입스크립트로 작성한 Node.js 서버가 잘 동작중이고, Request를 받았다면 이 객체의 type은 그냥 "object"라는 것이다. 이는 경우에 따라 생각보다 큰 문제는 아닐 수 있으나, 타입스크립트 사용시 언제나 반드시 고려해야 할 문제이다. 물론 TypeGuard 기능이나, io-ts, fp-ts 등의 함수형 라이브러리를 통해 함수형으로 런타임 타이핑까지 잡을 수 있지만, 아예 런타임에서 언어 차원의 타입 체크가 이뤄지는 것 보다는 항상 찜찜하다.

자바스크립트는 객체가 갖는 속성을 어떻게든 개발자가 파악해서 어떻게든 에러 없이 동작하도록 설계하는 것이 기본적인 개발 흐름이다. 반면 타입스크립트는 이토록 지나치게 자유로운(=위험한) 변수/객체 활용에 의도적으로 제약을 걸어 개발의 안정성 및 편의성을 증대시키는 것이 그 존재의의임에 유의할 필요가 있다.

특히 복잡한 객체를 안전하게 활용할 수 있도록 제공되는 타입스크립트의 대표적인 도구가 Advanced Type과 Utility Type인데, 이 기능들은 자바스크립트 뿐만이 아니라 다른 언어에서도 생소한 개념[17]이기 때문에 개발자들에게 익숙하지 않을 가능성이 상당히 높다. 모든 개발자가 문서를 한번 보고 응용 가능할 정도가 아니기 때문에, 첫 도입시에 이 부분을 간과하면 오히려 도입 전보다 생산성이 안좋아질 수도 있다는 점에 유의하는 것이 좋다.

또한 위와 같은 도구를 활용해서 기껏 엄밀하게 typing을 해놨더니 업계에서 흔히 있는요구 사항 및 기능 변경, 리팩토링 작업 등으로 인해 기능 구현에 더해 typing까지 덤으로 다시 해야 하는 불상사가 생길 수도 있다. 경우에 따라서는 아예 any 타입[18]로 도배하는 것만도 못한 결과가 초래될 수도 있다는 것. 따라서 적재적소에 타입스크립트의 기능을 도입하는 안목이 필요해질 수 있다.

npm 라이브러리를 Typescript에서 사용하기 위해서는 해당 라이브러리가 Typescript로 작성되었거나, d.ts를 통해 만들어진 Typescript용 타입지정 패키지가 별도로 있는 라이브러리만 정상적으로 사용할 수 있다. 유명한 라이브러리들은 대부분 Typescript 타입지정 패키지를 지원하지만, 일부 라이브러리의 경우 이런 것들을 지원하지 않는 경우가 있다.

이런 경우 //@ts-ignore 주석을 import문 위에 붙이거나 JS와 동일하게 require()를 사용하여 컴파일 오류 없이 라이브러리를 사용할 수는 있다. 물론 이렇게 불러온 라이브러리의 심볼들에 대해서는 타입 평가가 이루어지지 않기 때문에 Typescript의 장점을 활용하기 어렵다.