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

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

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

델파이와 C#의 개발을 주도한 Anders Hejlsberg가 개발에 참여하고 있다. 이 때문인지 일부 기능이나 문법은 C#와 유사하다.

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

백엔드와 프론트엔드 통합

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

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

프론트엔드

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

TypeScript는 마이크로소프트에서 2년간의 내부 개발 끝에 2012년 10월(버전 0.8)에 처음 공개되었다.

발표 직후 미겔 데 이카자는 언어 자체를 높이 평가하면서도 당시 Linux와 OS X에서는 이용할 수 없었던 마이크로소프트 비주얼 스튜디오와 별도로 성숙한 IDE 지원이 부족하다고 비판했다.

2021년 4월 현재 Emacs, Vim, Webstorm, Atom 및 Microsoft의 자체 Visual Studio Code를 포함한 다른 IDE 및 텍스트 편집기에서 지원이 이루어지고 있다.

2013년에 출시된 TypeScript 0.9는 제네릭에 대한 지원을 추가했다.

타입스크립트 1.0은 2014년 마이크로소프트 빌드 개발자 컨퍼런스에서 출시됐다.

Visual Studio 2013 업데이트 2는 TypeScript에 대한 내장 지원을 제공한다.

2014년 7월 개발팀은 새로운 TypeScript 컴파일러를 발표하면서 5배의 성능 향상을 주장했다.동시에, 처음에 CodePlex에서 호스트되었던 소스 코드는 GitHub로 이동되었다.

2016년 9월 22일 TypeScript 2.0이 출시되었으며, 프로그래머가 변수를 선택적으로 할당하지 못하도록 하는 기능 등 몇 가지 기능을 도입하였다.null가치관, 때로는 억만 달러의 실수라고 일컬어지기도 한다.

2017년 3월 타입스크립트가 구글의 사내 표준 언어 채택

TypeScript 3.0은 2018년 7월 30일에 출시되었으며, 휴식 매개변수 및 확산 표현, 튜플 유형이 있는 휴식 매개변수, 일반적인 휴식 매개변수 등 많은 언어 추가가 이루어졌다.

TypeScript 4.0은 2020년 8월 20일에 출시되었다.[26]4.0은 변화무쌍한 변화를 도입하지 않았지만, Custom JSX Factory, Variquadi Tuple Type 등의 언어 특징을 추가했다.