Lint

이번 글은 2020년 1월 15일에 서울대 SKT연구소에서 T아카데미 주관으로 진행된 <모던 프론트엔드 개발 환경의 이해>(강사: 김정환 님)라는 세미나의 필기 내용이다. 주요 내용 위주로 필기했기 때문에, 다른 글에 비해 흐름이 다소 병렬적일 수 있음에 양해바란다.

Lint

낡은 스웨터의 보푸라기 같은 것을 린트(Lint)라고 부른다고 한다. 코드에도 이런 보푸라기 같은 부분이 있으며 이를 정리하는 것을 린트 혹은 린터라고 한다.
보푸라기가 많은 코드를 작업하다 보면, 나도 모르게 한두개씩 수정하게 된다.(띄어쓰기를 한 칸 줄인다거나…) 이렇게 수정된 부분은 commit을 남기거나 Pull Request를 통해 다른 사람이 코드리뷰를 할 때 diff로 표시되어 전반적인 가독성이 떨어질 수 있다.

ESLint

npm i -D eslint와 같이 dev옵션으로 설치한다.
엄밀히 말하면, ESLint는 에러 방지 목적이 메인이다.
설정 파일인 .eslintrc.js를 프로젝트의 루트 경로에 둔다. 내용은 아래와 같이 모듈을 export하는 형태로 써주고, 이 안에 rules 또는 extends를 설정하게 된다.
```
module.exports = {}
```
npx eslint app.js와 같이 특정 파일(여기서는 app.js)을 대상으로 lint를 돌려볼 수 있다.

규칙(Rules)

문서의 Rules를 보면 선택 가능한 규칙들을 살펴볼 수 있다.
규칙은 off 또는 0로 끌 수 있고, warn 또는 1로 경고, error 또는 2로 오류로 처리할 수 있다.

설정 파일에서 아래와 같이 채워넣으면 나중에 lint를 실행할 때 이를 참고하게 된다.

// .eslintrc.js
module.exports = {
    rules: {
        "no-unexpected-multiline": "error"
    }
}

—fix 옵션

경고/에러만 띄우는 게 아니라 직접 고쳐주기도 한다. --fix 옵션을 활용하면 된다.
단, 모두가 가능한 것은 아니고 문서의 Rules 중 렌치 아이콘이 있는 규칙들만이 자동으로 fix가 가능하다.

Extensible Config

이미 세트로 묶어둔 여러 규칙들을 한번에 적용하는 방법이다.(마치 Babel의 preset처럼!)

// .eslintrc.js
module.exports = {
    extends: [
        "eslint:recommended", // 미리 설정된 규칙 세트을 사용한다
    ], 
}

airbnb 스타일도 유명한데, eslint-config-airbnb-base 패키지로 적용한다.

초기화

npx eslint --init를 사용하면, 정보입력을 채워 넣어서 .eslintrc 파일을 쉽게 만들 수 있다.

Prettier

npm i -D prettier와 같이 dev옵션으로 설치한다.
Prettier는 코드를 예쁘게/통일감있게 만드는 게 목적이다.
npx prettier app.js --write와 같이 쓰면 app.js를 prettier 스타일에 맞게 수정해준다.

ESLint와 Prettier의 통합

eslint-config-prettier

npm i -D eslint-config-prettier와 같이 dev 옵션으로 설치한다.
이는 ESLint와 Prettier간 상충되는 규칙을 해결해준다.(상충되면 ESLint의 규칙을 끈다.)

아래와 같이 설정파일에서 ESLint 설정들 외에 한줄 더 추가하는 식으로 작성한다.

// .eslintrc.js
{
    extends: [
        "eslint:recommended",
        "eslint-config-prettier"
    ]
}

npx prettier app.js --write && npx eslint app.js --fix로 검사한다.

eslint-plugin-prettier

npm i -D eslint-plugin-prettier와 같이 dev 옵션으로 설치한다.
Prettier의 규칙을 ESLint 규칙으로 추가하는 플러그인이다. 프리티어의 모든 규칙이 ESLint로 들어오기 때문에 ESLint만 실행하면 된다.

설정 파일에서 plugins 부분과 rules부분에 아래와 같이 작성한다.

// .eslintrc.js
{
    plugins: [
        "prettier"
    ],
    rules: {
        "prettier/prettier": "error"
    },
}

npx eslint app.js --fix와 같이 ESLint만 실행한다.

자동화/강제화

깃훅을 사용하여 precommit에서 검사하기

husky라는 도구를 사용하자. npm i -D husky로 설치한다.

package.json 내에 아래와 같이 작성하면 커밋전에 뭔가를 할 수 있다.

{
    "husky": {
        "hooks": {
        "pre-commit": "echo \"이것은 커밋전에 출력됨\""
        }
    }
}

위 코드에서 "echo \"이것은 커밋전에 출력됨\"부분을 "eslint app.js --fix"와 같이 수정하면 커밋 전에 자동으로 린트를 돌릴 수 있다.

변경된 파일만 검사하기

수정한 적도 없는데 굳이 매번 무의미하게 린트를 돌리면 시간과 리소스가 아깝다.
lint-staged라는 도구를 husky와 함께 사용하자. 스테이징된 파일만 린트를 돌릴 수 있게 해준다. npm i -D lint-staged로 설치한다.
lint-staged는 package.json 내에 아래와 같이 설정을 추가해줘야 한다. 아래와 같은 설정은, commit할 때 스테이징된 파일들 중에서 js파일만 린트를 돌리겠다는 의미다.
```
{
    "lint-staged": {
        "*.js": "eslint --fix"
    }
}
```

lint-staged만의 설정이 끝났으면, husky 설정도 수정해줘야 한다.

{
    "husky": {
        "hooks": {
        "pre-commit": "lint-staged"
        }
    },
}

이제 husky를 통해 늘 lint-staged를 사용하게 되었으니, husky 설정보다는 필요 시 lint-staged 설정만 조금 수정해가며 쓰면 되겠다.

[참고자료]
김정환, 모던 프론트엔드 개발 환경의 이해, 68차 토크ON세미나(2020. 1. 15.), T아카데미(SK Planet).

Published 15 Jan 2020

잘못된 내용이 있다면 Pull Request로 고쳐주시거나 혹은 Issue를 통해 제게 꼭 알려주세요! 댓글도 좋습니다.HyunSangHan > TIL on Github