배경
typescript는 javascript의 대부분의 기능을 포함하고있는 javascript의 범위를 감싸는 상위집합이다. 때문에 typescript를 사용하면 javascript의 모든 기능과 최신 ECMAScript 문법을 지원하면서 타입 지원까지 된다고 보면 된다.
javascript 프로젝트에서는 eslint를 사용하고, typescript 프로젝트에서는 tsconfig.json 설정을 통해 자체적으로 타입 체크가 지원 된다. 둘 다 소스코드 작성중이거나 트랜스파일 시점에 소스코드를 체크한다는 점에서는 닮은 점이 있지만 eslint는 소스코드 컨벤션과 관련이 있고, typescript는 개발자들의 실수 방지를 위한 목적이 크다는 점에서 둘은 목적이 다른 도구라고 할 수 있다.
아무튼 typescript 프로젝트에서는 옵션으로 eslint까지 사용할 수 있다.
eslint가 .ts 또는 .tsx 파일을 분석할 수 있도록 하기
eslint는 ECMAScript 즉 .js만을 기본적으로 지원하기 때문에 .ts와 .tsx를 .js와 같은 자원으로 인식하고 해석할 수 있도록 설정해야 한다. 이는 @typescript-eslint/parser를 설치하여 적용할 수 있다.
# ts를 해석하기 위한 파서와, 룰을 위한 플러그인을 같이 설치
yarn add -D @typescript-eslint/parser @typescript-eslint/eslint-plugin
parser 옵션에 @typescript-eslint/parser로 지정하고
plugins에 @typescript-eslint를 추가하면 rules에 ts를 위한 룰을 추가하여 .ts파일도 eslint를 지원하게 된다.
.eslintrc
{
"parser": "@typescript-eslint/parser",
"plugins": ["@typescript-eslint"],
"rules": {
// 원하는 룰 추가
"@typescript-eslint/rule-name": "error"
}
}
여기서 놓치기 쉬운 부분이 있는데 IDE가 소스코드에 빨간줄을 그어주는건 eslint 와 typescript 설정을 합쳐서 하나의 설정을 사용하는 것이 아니다. 룰에 위배되면 eslint 에러를 보여줄 뿐이고, tsconfig.json compilerOptions에 위배되면 해당하는 타입관련 에러를 보여주는 것 뿐이다.
react 프로젝트를 위한 설정
React17 기반의 타입스크립트 프로젝트를 위한 tsconfig.json
{
"compilerOptions": {
"lib": [
"dom",
"dom.iterable",
"esnext"
],
"allowJs": true,
"skipLibCheck": true,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
"noFallthroughCasesInSwitch": true,
"module": "esnext",
"moduleResolution": "node",
"resolveJsonModule": true,
"isolatedModules": true,
"target": "es5",
"noEmit": true,
"jsx": "react-jsx"
}
}
리액트 개발에는 noEmit: true 옵션을 활성화 한다. 그 외 오로지 .ts로 이루어진 패키지는. noEmit: false로 하여 tsc를 통해 transpile 할 수 있다.
typescript는 web에서 바로 사용될 수 없기 때문에 js로 변환하는 과정이 필요한데, tsc라는 도구를 통해서 .ts를 .js로 변환할 수 있다. 하지만 tsc는 같은 .ts 파일을 모듈로서 인식하고 .ts만을 .js로 변환해주기 때문에 웹페이지 개발에 필요한 이미지, css, font 등의 다양한 리소스를 해석하기 위해서는 별도의 번들러가 필요하다.
react개발에는 jsx라는 js와 xml이 혼합된 문법을 사용하는데, 이러한 jsx를 반환하는 함수 또는 jsx를 반환하는 render함수를 구현하도록 React.Component를 확장한 Class를 일반적으로 컴포넌트라고 한다.
컴포넌트는 HTMLElement, js, css, image 등의 자원을 모두 이용할 수 있는데 이런 자원들을 모듈로서 해석하여 최종적으로 SPA로 만들기 위해 webpack 또는 parcel과 같은 번들러를 이용한다.
번들러가 .ts를 해석할 때 tsc를 이용해서 빌드하는게 아니라 번들러가 별도의 .ts 모듈 로더를 통해 해석하고 변환하게 하기 위한 옵션이라는 것을 말하기 위함이다.
tsc를 이용하여 ts만 빌드하기 위한 설정
tsconfig.json
{
"compilerOptions": {
"outDir": "dist", <-- 소스를 어디로 emit 시킬건지
"lib": [
"dom",
"dom.iterable",
"esnext"
],
"allowJs": true, <-- ts가 js도 import하고싶다면 true
"skipLibCheck": true,
"esModuleInterop": true,
"allowSyntheticDefaultImports": true,
"strict": true,
"forceConsistentCasingInFileNames": true,
"noFallthroughCasesInSwitch": true,
"module": "esnext",
"moduleResolution": "node", <-- 모듈을 인식하기 위한 알고리즘 classic과 node가 있는데 일반적으로 node 방식을 따름
"resolveJsonModule": true,
"isolatedModules": true,
"target": "es6",
"noEmit": false, <-- false여야 tsc로 결과물을 내보낼 수 있다.
"noEmitOnError": true,
"declaration": true, <-- d.ts 타입 정의파일을 내보낼거면 true
"emitDeclarationOnly": false <-- d.ts만 내보낼거면 true 아니면 false 설정
},
"include": ["src"] <-- 빌드하기 위한 엔트리포인트
}
'frontend > 개발환경' 카테고리의 다른 글
babel은 ts를 어떻게 해석할까? (0) | 2021.12.13 |
---|---|
git hooks, husky, lint-staged (0) | 2021.12.13 |
monorepo에서 eslint 동작방식 정리 (0) | 2021.12.13 |
monorepo와 yarn workspace 소개 (0) | 2021.12.13 |
monorepo 프로젝트 시작하기 (0) | 2021.12.13 |