Posts [프론트엔드 개발환경의 이해와 실습] eslint 자동화하는 방법
Post
Cancel

[프론트엔드 개발환경의 이해와 실습] eslint 자동화하는 방법

eslint 자동화

린트는 코딩할 때마다 수시로 실행해야하는데 이러한 일은 자동화 하는 것이 좋다. "깃 훅을 사용하는 방법""에디터 확장 도구"를 사용하는 방법이 있다.

깃 훅을 사용하는 방법

소스 트래킹 도구로 깃을 사용한다면 깃 훅을 이용하는 것이 좋다. 커밋 전, 푸시 전 등 깃 커맨드 실행 시점에 끼여들수 있는 훅을 제공한다. husky는 깃 훅을 쉽게 사용할 수 있는 도구다. (Git 2.13.0 이상 버전을 지원) 커밋 메세지 작성전에 끼어들어 린트로 코드 검사 작업을 추가하면 좋겠다.

먼저 패키지를 다운로드 한다.

1
npm i -D husky

허스키는 패키지 파일에 설정을 추가한다.

  • package.json
1
2
3
4
5
6
7
{
  "husky": {
    "hooks": {
      "pre-commit": "echo \"이것은 커밋전에 출력됨\""
    }
  }
}

훅이 제대로 동작하는지 빈 커밋을 만들어 보자.

1
2
3
4
git commit --allow-empty -m "빈 커밋"
husky > pre-commit (node v13.1.0)
이것은 커밋전에 출력됨  ----> 깃 훅이 동작함
[master db8b4b8] empty

pre-commit에 설정한 내용이 출력되었다. 출력 대신에 린트 명령어로 대체하면 커밋 메세지 작성 전에 린트를 수행할 수 있겠다.

  • package.json
1
2
3
4
5
6
7
{
  "husky": {
    "hooks": {
      "pre-commit": "eslint app.js --fix"
    }
  }
}

만약 린트 수행중 오류를 발견하면 커밋 과정은 취소된다. 린트를 통과하게끔 코드를 수정해야만 커밋할 수 있는 환경이 되었다.

한편, 코드가 점점 많아지면 커밋 작성이 느려질 수 있는데 커밋전에 모든 코드를 린트로 검사하는 시간이 소요되기 때문이다. 커밋시 변경된 파일만 린트로 검사하면 더 좋지 않을까?

lint-staged변경된(스테이징된) 파일만 린트를 수행하는 도구다.

패키지를 설치하고,

1
npm i -D lint-staged

패키지 파일에 설정을 추가한다.

  • package.json
1
2
3
4
5
{
  "lint-staged": {
    "*.js": "eslint --fix"
  }
}

내용이 변경된 파일 중에 .js 확장자로 끝나는 파일만 린트로 코드 검사를 한다.

pre-commit 훅도 아래처럼 변경한다.

  • package.json
1
2
3
4
5
6
7
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
}

커밋 메세지 작성전에 lint-staged를 실행할 것이다. 이제 커밋하면 모든 파일을 검사하는 것이 아니라 변경되거나 추가된 파일만 검사한다. 커밋 과정이 훨씬 가벼워질 것이다.

Note: 이런식으로 코드 검사하는 부분을 자동화해야만 일관적인 코드 구조를 유지할 수 있다.

에디터 확장도구

코딩할때 실시간으로 검사하는 방법도 있다. vs-codeeslint와 prettier 익스텐션이 그러한 기능을 제공한다. 프리티어 규칙을 ESLint와 통합했기 때문에 ESLint 익스텐션을 사용해 보겠다.

먼저 ESLint 익스텐션 부터 설치해 보자.

스크린샷 2022-03-26 오후 6 58 09

설치를 마친 뒤 eslint를 활성화 설정을 추가한다.

  • .vscode/settings.json:
1
2
3
{
  "eslint.enable": true
}

설치하면 자동으로 ESLint 설정파일을 읽고 파일을 검사한다.

스크린샷 2022-03-26 오후 7 04 48

툴팁 메뉴를 클릭해서 문제를 수정한다.

에디터 설정중 저장시 액션을 추가할 수 있는데 ESLint로 코드를 정정할 수 있다.

  • .vscode/settings.json:
1
2
3
4
5
{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

이렇게 ESLint 익스텐션으로는 실시간 코드 품질 검사를 하고 저장시 자동 formatting 을 하도록 하면 실시간으로 코드 품질을 검사하고 포맷도 일관적으로 유지할 수 있다.

정리

읽기 좋은 코드는 유지보수 하기좋다. 그만큼 어플리케이션의 수명은 오래갈 수 있다. 여럿이서 함께 일하는 환경에서 손으로 코드를 관리하는 것은 무척 번거럽고 어쩌면 불가능한 일일지도 모른다. 규칙이 정해졌고 자동화할 수 있다면 도구의 도움을 받는 것이 현명하다.

ESLint는 오류와 버그의 가능성을 찾아 코드 품질을 높이는 역할을 한다. 프리티어는 코드를 일관적으로 포매팅하기 때문에 읽기 수월한 코드를 만들어 준다. 이러한 도구를 개발 플로우의 적절한 시점에 통합하여 자동화하면 개발자는 좀 더 본질적인 코딩에 집중할 수 있을 것이다.

출처

This post is licensed under CC BY 4.0 by the author.

[프론트엔드 개발환경의 이해와 실습] 프리티어(Prettier)

[프론트엔드 개발환경의 이해와 실습] 웹팩 API 서버 연동