원문: The future of TypeScript on ESLint
https://eslint.org/blog/2019/01/future-typescript-eslintESLint에서 TypeScript의 미래
몇 주 전, TypeScript 팀은 그들의 저장소에 ESLint를 공식적으로 도입하면서 ESLint에 대한 TypeScript 호환성 개선 작업에 대한 로드맵을 공유했습니다.
Linting
- ESLint의 의미 규칙
- TSLint와 패리티 (TSLint 오류 검출)
- 속도 및 확장성
- ESLint를위한 에디터 통합
몇 달 전에 VS Code에서 실시한 설문 조사에서, 사용자로부터 들었던 가장 빈번한 주제는 Lint 사용성이 많이 아쉽다는 것입니다. 그때부터 우리 팀 일부는 JavaScript에서의 사용성을 고치는데 전념했고, 수정하는 팀은 TSLint와 ESLint에 대한 지원을 추가하기 시작했습니다. 하지만 우리는 TSLint 규칙이 작동하는 방식에 성능에 영향을 미치는 몇 가지 아키텍처 문제가 있음을 알았습니다. 보다 효율적으로 작동하도록 TSLint를 수정하려면 기존 규칙을 위반하는 다른 API가 필요합니다 (wotan이 제공하는 것과 같이 interop API를 구축하지 않는 한).
한편 ESLint는 이미 우리가 찾고있는 고성능의 아키텍처를 가지고 있습니다. 게다가, 사용자에 의한 각각의 커뮤니티에 종종 ESLint는 지원하지만 TSLint는 지원하지 않은 Lint 규칙들(예 : React Hooks 또는 Vue 규칙)이 있습니다.
이를 감안할 때 편집 팀은 중복작업을 하는 대신 ESLint를 활용하는 데 중점을 둘 것입니다. ESLint가 현재 다루지 않는 시나리오 (예: 시맨틱 린팅 또는 프로그램 전체 린팅)를 위해서 우리는 ESLint의 TypeScript 지원이 TSLint 수준이 되도록 기여하는 작업을 할 것입니다. 이것이 실제로 어떻게 작동하는지에 대한 초기 테스트 베드로서 TypeScript 저장소를 ESLint를 사용하도록 전환하고 새로운 규칙을 업스트림으로 보내는 중입니다.
우리는 많은 JavaScript 및 TypeScript 커뮤니티와 마찬가지로이 발표에 매우 흥분했습니다. ESLint 팀의 몇몇 구성원은 지난 몇 년 동안 James Henry, Kai Cataldo, Kevin Partington, Toru Nagashima 및 Nicholas Zakas를 포함하여 TypeScript 호환성을 개선하기 위해 노력해 왔습니다. 이 작업은 주로 TypeScript 파서 typescript-eslint-parser(및 부분적으로는 ESLint 팀이 유지 관리하진 않지만 최근까지 Nicholas와 James가 유지 관리했던 eslint-plugin-typescript)에 중점을 두었습니다. Typescript 파서는 의심할 여지 없이 앞으로 TypeScript-in-ESLint 스토리의 중심이 될 것입니다. 따라서, 우리는 TypeScript가 적절하게 유지될 수 있기를 원했습니다.
typescript-eslint프로젝트 발표
오랫동안 ESLint의 TypeScript 호환성의 원동력이 되어 온 James Henry는 TypeScript ESLint 호환성과 관련된 모든 것을 위해 중앙 저장소와 같은 typecript-eslint 프로젝트를 시작했습니다. 이것은 TypeScript 파서 eslint-plugin-typescript의 새로운 둥지이자 TypeScript ESLint 환경을 최대한 원활하게 만드는 또 다른 유틸리티입니다.
ESLint 팀은 새로운 프로젝트에 공식적으로 참여하지는 않지만 James의 노력을 전적으로지지하며 TypeScript 개발자에게 최고의 ESLint 사용성을 보장하기 위해 커뮤니케이션 라인을 열어 둘 것입니다.
이것이 앞으로 의미하는 것
- ESLint 팀은
typescript-eslint-parser를 더 이상 유지하지 않습니다
- 저장소는 오늘부터 보관됩니다
typescript-eslint-parsernpm에는 더 이상의 릴리스가 없습니다.
typescript-eslint-parser를 사용하는 사람은 그 대신@typescript-eslint/parser를 사용해야합니다.- TypeScript 지원이 어떻게 진행되는지에 관심이있는 사람들은
typescript-eslint저장소를 따라야 합니다.
다시 한 번, 우리는 TypeScript 커뮤니티를 ESLint 커뮤니티 안으로 맞이하게 되어서 매우 흥분되고, James와typescript-eslint팀이 어떻게 ESSLint를 TypeScript 코드 린팅에 가장 적합한 선택으로 만드는지 보게되어 매우 기대된다.
역자 요약
- 2019년 1월~6월까지 해당 작업 예정이었으며, 현재 릴리즈가 되긴했음. 안정화는 확인해 봐야할 듯.
- 기존에 쓰던
typescript-eslint-parser대신@typescript-eslint/parser를 써야함. 한마디로 package.json에typescript-eslint-parser라는 문자열이 보이면 안됨 - eslnt보다 tslint가 느린 이유가 트리(AST) 탐색 로직이 다르다는 것 같은데, TSLint(타입체크)를 위해서는 ESLint와 다르게 참조를 타고 가서 확인하는 과정이 필요해서 라는 얘기 같음.
- 두 Lint가 합쳐지는 것은 매우 반가운 일. 두가지를 동시에 설정하는 게 영 번거로웠음.
- 이제 TSLint, ESLint 따로 환경 설정할 필요 없이 ESLint만 있으면 됨. 그리고 Prettier 및 jscodeshift 같은 거 안써도 되는 방향으로 나가려는 것 같음.
참고링크:
https://github.com/Microsoft/TypeScript/issues/29288#roadmap-overview
NAVER D2 아티클(TypeScript의 영향력 확장 부분 참고)
https://d2.naver.com/helloworld/2108442
Vue의 typescript
https://kr.vuejs.org/v2/guide/typescript.html
2017 에반뉴의 글
https://medium.com/the-vue-point/upcoming-typescript-changes-in-vue-2-5-e9bd7e2ecf08
용어:
AST(abstract syntax tree) 추상 구문 트리
https://ko.wikipedia.org/wiki/%EC%B6%94%EC%83%81_%EA%B5%AC%EB%AC%B8_%ED%8A%B8%EB%A6%AC
그냥 트리구조 도식화를 의미한다고 보면될 듯.
tr;dr
"too long; didn't read" 인터넷 속어
https://ko.wikipedia.org/wiki/TL;DR
