티스토리 뷰
스토리북 관련 작업을 하던 도중
The base Typescript configuration uses babel-loader for Typescript transpilation, and optionally fork-ts-checker-webpack-plugin for checking.
라는 문장을 만났는데 fork-ts-checker-webpack-plugin이라는게 무슨 역할을 하는건지 궁금해서 정리합니다.
Fork TS Checker Webpack Plugin
typescript의 타입을 분리된 프로세스에서 체크해주는 웹팩 플러그인입니다.
만들어진 이유
웹팩이 타입스크립트 파일을 만나면 그 파일을 해석하기 위해서 첫번째로 로더가 필요합니다. awesome-typescript-loader와 CheckerPlugin(분리된 프로세스에서 타입을 체크해줌)를 조합해서 타입스크립트 컴파일과 타입체크를 동시에 하곤 했었습니다. 근데, 문제는 awesome-typescript-loader가 ts-loader에 비해서 증분빌드(incremental build)가 매우 느리다는 겁니다.
그래서 우리는 ts-loader를 사용하고 ts-loader에 type checker를 붙이기 위해 이 fork-ts-checker-webpack-plugin을 제작했습니다. 성능을 개선하기 위해 이 플러그인은 컴파일된 AST를 tslint와 공유합니다.
AST란, Abstract Syntax Trees, 추상 문법 트리 (컴파일 되어 트리형태로 파싱된 타입스크립트 문법)을 의미합니다.
eslint가 있는데 왜 또 type checker를 사용해야하는지?
eslint와 type checker의 목적은 똑같다. 코드가 실행되기 전에 컴파일타임에 미리 에러를 잡아내자는 목적이다. 근데 방법은 서로 다르다.
eslint의 경우에는 문법적으로 잘못된 부분을 바로잡아주는 역할을 하고,
type checker의 경우에는 함수나 클래스들이 타입에 맞게 정확히 작성되었는지를 검사해주는 역할을 한다.
따라서, eslint와 type checker를 동시에 쓸수도있고 둘중 하나만 쓸수도있다. 하지만 eslint의 경우에는 보통 필수로 사용하는 편이다.
'Typescript' 카테고리의 다른 글
typescript의 unknown과 never 타입 (1) | 2020.07.16 |
---|---|
typescript의 never타입 (0) | 2020.07.16 |
스토리북 typescript bug, import된 타입을 불러오지 못하는 현상 (0) | 2020.05.29 |
typescript + react eslint룰 설정 (0) | 2020.05.29 |
Type vs Interface 어떤것을 써야할까? (0) | 2020.04.13 |
- Total
- Today
- Yesterday
- props
- reactdom
- return type
- es6
- promise
- javascript
- useRef
- storybook
- mobx
- Action
- computed
- react hooks
- rendering scope
- react
- server side rendering
- webpack
- Next.js
- atomic design
- design system
- await
- reflow
- reducer
- async
- useEffect
- state
- typescript
- Polyfill
- Babel
- type alias
- hydrate
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |