이 글은 Medium 글을 참고하여 작성하였습니다.

TSLint와 ESLint의 오늘

오늘날 TSLint는 사실상 Typescript 구현 자체 및 Typescript 레포지토리의 표준 Linter 입니다. TSLint에 구성된 에코 시스템은 사용자 정의 규칙 및 구성 패키지와 함께 핵심 규칙 세트로 구성됩니다.

한편 ESLint는 표준 Javascript Linter 입니다. TSLint와 마찬가지로 핵심 규칙 세트와 사용자 정의로 구성됩니다. ESLint는 자동 들여쓰기 등과 같이 TSLint에서 누락된 많은 기능을 지원합니다. 반대로 ESLint 규칙은 Typescript에서 제공하는 정적 분석 및 형식 유추로부터 최소한의 장점을 누릴 수 없으므로 TSLint의 Lint 규칙에서 다루는 버그 및 코드를 추출할 수 없습니다.

Typescript + ESLint

Typescript팀의 전략적인 방향은 "모든 js 개발자들을 위해 모든 환경의 유형을 지원하는 것" 입니다. 다시 말해서, Typescript 및 Javascript 개발자 경험이 수렴 될 때까지 유형 및 정적 분석과 같은 Typescript 기능을 통해서 Javascript 개발자 경험을 점진적으로 향상 시키는 것 입니다.

ESLint는 Javascript Linting을 위한 선택 도구입니다. 따라서, Typescript의 공간을 분리하지 않기 위해서 TSLint를 더이상 사용하지 않고 ESLint의 Typescript 지원을 개선하는데 집중할 계획입니다. 이렇게 집중하는 것이 올바른 방향이라고 생각되는 전략적이고 실용적인 이유가 있습니다.

• 개발자 접근성 : Javascript 개발자가 Typescript로 전환하는 데 장애가 되는 것 중 하나는 ESLint에서 TSLint로 진행하는 간단한 마이그레이션 입니다. 개발자가 기존 ESLint 설정에서 시작해서 점차 Typescript에 관련된 정적 분석을 추가 할 수 있게 되면 접근성이 개선될 수 있습니다.
• 커뮤니티 통합: ESLint와 TSLint의 핵심은 동일한 규칙 세트와 광범위한 플러그인 포인트를 통해 개선된 개발 경험을 제공하는 것입니다. ESLint 내에서 Typescript의 구문 분석을 사용할 수 있게 되었으므로, 각 도구를 통해 조각화를 유지하는 것이 아닌 커뮤니티의 표준화를 도모할 수 있습니다.
• 보다 성능이 뛰어난 분석 인프라: ESLint API를 사용하면 특정 클래스의 검사를 효율적으로 구현할 수 있습니다. TSLint의 API 리팩토링이 가능할 지라도 ESLint의 아키텍쳐를 활용하고 개발 리소스를 다른곳에 집중시키는 것이 현명하다고 판단된듯 합니다.

사용법

현재 기준 (2020.02.16) eslint + tyescript 연동 방법을 기재하였습니다.

1) @typescript-eslint 설치

npm 내에 @typescript-eslint 관련 플러그인을 설치합니다.

npm i @typescript-eslint/eslint-plugin @typescript-eslint/parser

2) eslintrc 설정 추가

.eslintrc 내에 설정을 추가합니다.

// .eslintrc
{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],
  "extends": [
    "plugin:@typescript-eslint/eslint-recommended"
  ]
}