환경설정

항상 이렇게 해줄 필요는 없음. 프레임워크를 사용하면, 그 안에 ts 환경도 맞춰져 있는데, 프레임워크 없이 ts를 설치하는 것을 다루는 방법임. 그러니 프레임워크 안에서 ts를 사용한다면, 그와 관련된 환경설정을 보는 것을 추천

<참조> source code github

npm init -y

npm i -D typescript

src 폴더 -> index.ts 생성

// index.ts 
const hello = () => "hi";

// 설치
// 이 파일이 있으면, vscode는 우리가 ts로 작업한다는 것을 알게 되고, ㅈ자동완성 기능을 제공해줌. 
touch tsconfig.json 

tsconfig.json
ts에게 가장 먼저 알려줘야하는 것은, 어디에 ts 파일이 위치하는 것

-> ts가 src 모든 파일을 확인한다는 것을 의미함.

// tsconfig.json
{
  "include": ["src"],
  "compilerOptions": {
    "outDir": "build"
  }
}

-> outDir : 자바스크립트 파일이 생성될 디렉토리를 지정.

// package.json
{
  "name": "typechain",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "build" : "tsc"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "typescript": "^4.7.4"
  }
}

npm run build

-> ts가 코드를 컴파일해서 낮은 버젼의 js 코드로 바꿔줌.
-> 어떤 버전의 js로 바뀔지 정할 수도 있다.

target은 어떤 버전의 js로 ts을 컴파일하고 싶은지를 나타낸다.
ES3 -> ES6로 변경

-> TS는 코드를 확인해줄 뿐만 아니라 호환되는 코드로 컴파일해줄 수 있다.

브라우저는 ES6의 모든 기능을 지원하므로, ES6를 사용하는 것이 가장 좋은 선택.
-> 브라우저를 위한 JS를 만들고 싶다면 ES6는 좋은 선택

lib : 합쳐진 라이브러리의 정의 파일 을 특정해주는 역할.
-> ts는 내장된 js api를 위한 기본적인 타입 정의를 가지고 있다.

기본적인 타입 정의란 ?

• ts에게 localStorage의 구조, argument, return 값과 return type을 설명해준 것

왜 타입 정의를 사용하느냐?

• 기본적인 패키지, 프레임워크, 라이브러리는 js로 만들어졌음. js로 만들어진 라이브러리를 ts 프로젝트에 사용하려고 하면, type에 대해 알 수가 없음.
  -> js 코드가 어디에서 동작할지 알려준다.

-> ES6를 지원하는 서버와 DOM, 즉 브라우저 환경에서 코드를 실행시킨다.
차이점 : DOM을 lib에 포함시켜두고, ts 코드에서 document를 쓰면 ts는 document가 가지고 있는 모든 이벤트와 메소드를 보여주고 있다. ts는 그에 대한 설명도 모두 해준다.
-> ts는 이 모든 자동완성을 제공해준다.
-> ts가 브라우저의 API와 타입들을 알고 있기 때문에
ex) 'DOM'을 지우면, TS는 브라우저를 위한 코드를 작성하는 것을 모른다.

ts는 js를 어떻게 인식할까? in node_modules에 설치된 JS 모듈을 (npm)

<<동작과정만 알아보지, 실상에서는 잘 사용되진 않으니 걱정 nono>>

// myPackage.js
// js 코드를 ts로 어떻게 인식하는지 알아볼거야. 그러기 위해서 js 파일을 하나 생성해줬어. 
export function init(config) {
  return true;
}
export function exit(code) {
  return code+1; 
}

// tsconfig.json
{
  "include": ["src"],
  "compilerOptions": {
    "outDir": "build",
    "esModuleInterop": true,
    "target": "ES6",
    "lib": ["ES6", "DOM"],
    "strict": true
  }
}

// index.ts 
// 빨간색 에러가 뜰 거야. 
import { init } from "myPackage";

빨간색 에러가 뜰 수 밖에 없는 이유는 ts가 type을 인식하지 못했기 때문이야.

// myPackage.d.ts d -> document의 약어라고 생각하면 될 듯 
// call signature을 적어주면 된다.
// 즉, ts에게 type만 적어주면 된다. 
interface Config {
  urls:string;
}

declare module "myPackage" {
  function init(config:Config) : boolean;
}

이렇게 적어주게 되면, myPackage의 call signature을 알 수 있다. -> 에러가 사라짐.

실제 완벽하게 type 정의를 볼 수 있다.

이러한 방식으로 typescript는 localStorage의 모양을 알 수 있다.

JSDoc

// tsconfig.json
// allowsJs -> 타입스크립트 안에 JS를 허용한다. 
{
  "include": ["src"],
  "compilerOptions": {
    "outDir": "build",
    "esModuleInterop": true,
    "target": "ES6",
    "lib": ["ES6", "DOM"],
    "strict": true,
    "allowJs": true,
  }
}

ts는 js도 보호해준다.

-> myPackage.d.ts 파일 삭제해야함.

@ts-check는 ts 파일에게 js 파일을 확인하라고 알림
-> js 파일 그대로 사용하고 싶지만, ts가 제공하는 보호 장치를 사용하고 싶을 때
-> JSDoc라는 것을 사용함.

JSDoc : 코멘트로 이루어진 문법, 함수 바로 위에 적어주면 됨.
-> 제대로 작성하면 ts가 코멘트를 읽을 수 있다.
-> ts를 이용하면 입력값이나 리턴값 모두 타입을 지정할 수 있다.
-> ts는 js 파일에서도 같은 작업을 할 수 있다.

// myPackage.js 
// @ts-check
/**
 * 아래는 코드 안에 코멘트를 적고 있을 뿐이다. 
 * 타입스크립트는 이 코멘트를 읽고 타입을 확인해줄 것이다. 
 * 코멘트일 뿐이지만, 타입스크립트가 도와주고 있다.
 * 꼭 코멘트 내용대로 맞추지 않고, 실행해도 문제 없다. 
 * Initializes the project
 * 이 함수는 입력값을 받을 것이고, 입력값의 데이터 타입은 객체가 될 것이다.  
 * 입력값의 이름은 config
 * @param {object} config 
 * config 객체 안에는 boolean이 있을 것이다.
 * @param {boolean} config.debug
 * @param {string} config.url
 * @returns {boolean}
 */
export function init(config) {
  return true;
}

/**
 * Exits the program
 * @param {number} code 
 * @returns {number}
 */
export function exit(code) {
  return code+1; 
}

-> 타입스크립트가 자바스크립트 파일을 확인해주고 있다.

-> 잘 나옴.