이전 포스트에서 Webpack과 TypeScript, React 개발 환경까지 세팅했었다.
이제 여기에 ESLint와 Prettier를 적용시키려고 한다.

1. ESLint

ESLint는 코드를 분석하여 안티-패턴이나 문법 오류를 찾아내어 알려주는 라이브러리다. 컴파일 단계에서 오류를 찾아낸다는 점에서 TypeScript와 비슷한 역할이다. 또한 ESLint의 코드 가이드를 벗어나면 Error 혹은 Warning을 반환하여 일관된 코드 스타일을 가질 수 있게 해준다.

우선 yarn add -D eslint 명령어로 eslint부터 설치한다. 그리고 eslint의 설정파일인 .eslintrc 를 생성해야 한다. 나는 npx eslint --init 명령어로 생성했다. 터미널에서 이 명령어를 실행하면 몇 가지 질문에 응답해야 한다. 그리고 응답내용을 기반으로 .eslintrc 파일이 생성된다.

// .eslintrc.json
{
    "env": {
        "browser": true,
        "es2021": true
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
        "plugin:@typescript-eslint/recommended"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 12,
        "sourceType": "module"
    },
    "plugins": [
        "react",
        "@typescript-eslint"
    ],
    "rules": {
    },
    "ignorePatterns": ["webpack.config.js", ".eslintrc.js"]
} 

내 생각에 눈여겨 보아야 할 옵션은 parser, plugins, extends, rules 이다.

parser 옵션은 ESLint에서 사용할 parser를 설정할 수 있다. ESLint는 JS코드를 AST구문으로 파싱한 뒤 Lint와 rules를 어긴 코드를 찾아낸다.(이에 대한 자세한 설명은 Kakao Tech - ESLint 조금 더 잘 활용하기에서 볼 수 있다.) 그런데 TypeScript 코드를 만나면 ESLint가 이해하지 못 하니까 typescript parser를 사용한 것이다.
plugins 옵션은 rules의 집합이다. 하지만 plugins를 등록했다고 해서 rules가 바로 적용되는 것이 아니고, plugin이 가지고 있는 rules 중 내가 사용할 rules를 직접 세팅해야한다.
extends 옵션은 babel의 presets 같은 역할을 한다. plugin이 가진 rule을 하나하나 살펴보면서 등록하긴 번거로우니 extend를 불러옴으로써 rules를 한 번에 적용시켜 준다. eslint:recommended같은 경우 eslint의 rules를 추천하는 구성으로 적용시켜주고, plugin:react/recommended는 plugins[react]의 rules를 추천하는 구성으로 적용시켜준다.
rules옵션은 내가 등록한 plugins의 rules를 직접 커스터마이징 할 수 있는 옵션이다.

그리고 ignorePatterns는 내가 임의로 넣었는데, 이 배열에 등록한 파일은 ESLint의 검사에서 제외한다. 현재의 config파일들에 ESLint를 사용할 필요는 없다 생각해서 config파일들을 검사에서 제외시켰다.

그리고 VS Code를 사용한다면 Extensions에서 ESLint를 설치해서 적용해야한다. 그래야 ESLint가 바로 적용된다.

ESLint Extension이 잘 적용되었다면 오른쪽 아래에 ESLint 항목이 추가된다. 옆에 ✔표시가 있다면 잘 작동하고 있다는 의미다. ⚠표시가 있다면 뭔가 잘못되어 작동이 안 되고 있다는 뜻이니 클릭해서 오류사항을 읽고 해결해야한다.

나는 잘 작동해서 현재 코드의 오류들을 짚어주고 있다.

App 함수 컴포넌트의 return 타입이 지정되지 않았다고 경고중이다. @typescript-eslint/explicit-module-boundary-types rule을 어겼다고 나와있다.

ReactElement type을 반환한다고 설정해주니 경고가 사라졌다. ESLint는 기본적으로 이런 역할을 한다.

2. Prettier

Prettier는 코드 스타일을 일관되게 만들어주는 라이브러리다. yarn add -D prettier로 설치하면 된다. Prettier도 extensions에서 추가해주어야 한다.
적용이 잘 되었다면 ESLint처럼 화면 오른쪽 아래에 Prettier 항목이 생긴다.

Prettier도 설정 파일을 통해 커스터마이징이 가능하다. 루트 디렉토리에 .prettierrc 파일을 생성한 뒤 옵션을 적용하면 된다.

// .prettierrc

{
  "arrowParens": "avoid",
  "bracketSpacing": true,
  "htmlWhitespaceSensitivity": "css",
  "insertPragma": false,
  "jsxBracketSameLine": false,
  "jsxSingleQuote": false,
  "printWidth": 80,
  "proseWrap": "preserve",
  "quoteProps": "as-needed",
  "requirePragma": false,
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "none",
  "useTabs": false,
  "vueIndentScriptAndStyle": false
}

Prettier Options Docs에서 Prettier의 모든 옵션에 대한 정보를 볼 수 있다.

3. ESLint와 Prettier 충돌

ESLint와 Prettier를 동시에 사용하려 할 때 만약 상충하는 설정이 있다면 충돌이 일어난다. 그런 상황을 미연에 방지하기 위해 Prettier를 ESLint와 통합시킬 수 있다.
yarn add -D eslint-plugin-prettier eslint-config-prettier 명령어로 eslint의 prettier plugin과 config를 설치하고, 적용한다.

// eslintrc.json

{
    "env": {
        "browser": true,
        "es2021": true
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
        "plugin:@typescript-eslint/recommended",
        "prettier"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 12,
        "sourceType": "module"
    },
    "plugins": [
        "react",
        "@typescript-eslint",
        "prettier"
    ],
    "rules": {
    },
    "ignorePatterns": ["webpack.config.js", ".eslintrc.json"]
}

이러면 충돌이 일어나지 않는다.

---

🍊

이렇게 CRA를 사용하지 않고 프로젝트 개발환경을 구축하기 시리즈는 끝났다. 처음이라 많이 미숙하기도 하다.

개발환경이 프로젝트의 반이라고 누가 이야기했던가? 어느정도 맞는 말이라고 생각한다.

이 시리즈는 CRA로만 프로젝트를 만들다보니 내 프로젝트가 어떤 라이브러리를 사용하는지, 왜 사용하는지, 어떻게 커스터마이징을 할 수 있는지 모르는 일이 발생해서 시작하게 된 시리즈다.
시리즈를 진행하면서 느낀 것은 내가 그동안 개발환경에 대해 관심이 없었다는 것이다. 사실 개발환경에 대해서 알아야한다고 생각했으면서 모른 척 해버린 걸 수도 있다.
그리고 역시 모르는 건 직접 하면서 배워야한다. 잘 안 되면 반복해서 숙달해야 하고.

혹시 개발환경을 직접 구축하는 법을 배우고자 이 글을 보는 분이 있다면, 나도 했으니 당신도 할 수 있다 라는 말을 꼭 해드리고싶다.