ESLint & Prettier, Git Hook(Husky) 사용으로 팀의 능률 올리기

1. Lintter & Code Formatter

• 한 프로젝트에서 작업자마다 각자 다른 코딩 스타일을 가지고 있고, 그것이 코드에 드러난다면 이 프로젝트를 제 3자가 읽기도 어려워지며, 팀원들끼리도 다른 팀원들이 작성한 코드를 읽고 이해하기가 힘들질 수 있다.
• 이러한 요소들은 결국 비효율을 유발하게되고 이를 극복하기 위해서 팀으로 작업을 할 때는 여러 작업자들의 코딩 스타일을 일치시키기 위한 Lintter와 Code Formatter를 사용하는 것이 좋다.
• 이러한 도구들을 사용하게 되면 어떤 형태의 문법을 지향하고 지양할지, 포맷팅은 쌍따옴표를 사용할지, 홑따옴표를 사용할지, 혹은 몇 자마다 줄바꿈을 할지, 문장의 끝에 세미콜론을 사용할지 등의 여부를 고민하지 않고 코드 작성 자체에 집중할 수 있도록 도와준다.
• 자바스크립트 진영에서는 Linter로 ESLint를, Code Formatter 로는 Prettier를 사용하는것이 일반적
• 앞서 설명한 ESLint는 코드 자체의 문법 교정과 더불어 코드 스타일링 기능도 포함
• 그러나 Prettier는 자동으로 코드의 스타일을 맞춰주는 보다 강력한 기능을 지원하고 있기 때문에 빈번히 ESLint와 함께 사용되고 있다.
• 때문에 일반적으로 Lintting 기능은 ESLint에, Code Formatting은 Prettier에 일임하는 방식으로 사용
• 코딩스타일은 팀에서 정할 수 있습니다. 다만 이를 개인에게 위임해서 개인이 의식적으로 지키는 것은 쉽지 않고 강제성이 없기에 취약하다.
• 그리고 코딩 스타일 관련 논쟁이 이어지다보면 상호 코드를 읽고, 리뷰하고, 작성하는데에도 많은 에너지가 소모된다.
• 이러한 불필요한 에너지 소모를 줄이기 위해서 코딩 스타일 자동화 툴이 필요!
• 따라서 자동화 될 수 없는 컨벤션은 최소화 하는것이 좋고 필요한 경우에는 반드시 문서화 시켜서 논의할 때 문서를 기준으로 의견을 주고받고 수정이 필요한 경우에는 논의결과가 문서에 반영되어야 한다.
• 이런 자동화 툴들은 아무것도 없이 시작하는 것 보다 초기세팅은 다소 복잡할 수 있지만, 한번 해두면 추후에 적용하기도 쉽고, 무엇보다 초기에 세팅해둔 것이 지속적인 개발 생산성 향상에 도움을 준다.

 

2. ESLint

• 일관되고 버그를 피할수 있는 코드를 짜기위해서 만들어진 코드 분석 툴
• 작성된 코드의 구문을 분석하여 버그가 발생할 여지가 있거나, 불필요한 코드, 혹은 보안상 위험한 코드 등에 대한 경고를 띄워준다.
• 설정 커스터마이징을 허용해주기 때문에 필요한 규칙들을 커스텀해서 적용가능하다.

 

3. Prettier

Prettier removes all original styling and ensures that all outputted code conforms to a consistent style.

Prettier · Opinionated Code Formatter

• 코드 포맷팅 툴
• 포맷팅 룰을 커스터마이징할 수 있다
• 코드의 포맷팅을 툴을 사용함으로서 팀원 모두가 같은 포맷팅스타일을 공유할 수 있게 된다.
• 그로인해서 개발자는 포맷팅등 다소 중요하지 않은 요소들에 에너지를 낭비하지 않고 핵심적인 개발에 집중할 수 있게 된다.

 

4. 설치

1. eslint
   • npm install eslint --save-dev
   • CRA의 경우 내장되어 있기 때문에 따로 설치하지 않아도 됨
2. prettier
   • npm install prettier --save-dev
3. eslint-config-prettier
   • eslint는 linting 기능을, prettier는 formatting을 담당하는 구조가 이상적
   • 하지만, eslint에는 일부 formatting 관련된 rule도 포함되어 있음
   • 이 rule들이 prettier와 다른 설정을 가지고 있다면 설정 충돌이 발생함
   • 따라서, eslint에서 formatting 관련 rule들을 모두 해제해야할 필요가 있음 수 동으로 진행할 수도 있지만, 이를 적용해주는 eslint plugin이 존재
   • npm install eslint-config-prettier --save-dev
4. optional
   • package들을 설치하면 terminal에서 명령어를 통해서 eslint와 prettier를 실행할 수 있음, IDE에서는 일반적으로 terminal 명령어로 실행하는 것 뿐만 아니라, 에디터 차원에서 파일을 저장할 때 formatting을 적용해주고, 에디터에서 eslint의 메세지들을 확인할 수 있게 해주는 기능들을 플러그인 형태로 제공하기에 원할시 사용할 수 있음

 

5. 설정

• 위와 같이 패키지들을 설치하면 이제 eslint와 prettier를 사용할 수 있게 되었지만, 아직 완벽하지 않음
• 패키지는 사용할 수 있지만 아직 팀원들간의 일관적인 규칙을 적용하지는 않은 상태
• 실제 프로젝트에서는 기본 설정을 그대로 사용하는 것이 아니라 팀에 맞게 커스터마이징해서 사용하며, 팀원들간 항상 똑같은 설정을 사용하는 것이 보장되어 있어야 하기에 eslint와 prettier는 프로젝트내에 설정파일을 이용해서 설정을 공유하고 적용하는 방법을 제공해주고 있음

5-1. Prettier 설정

• Prettier는 프로젝트의 루트 디렉토리에 .prettierrc.확장자 파일을 통해서 설정을 할 수 있음
• 설정파일의 확장자 형식은 다양하게 지원하고 있습니다(JSON, YAML, JS, TOML)
• prettier 설정은 포맷팅에만 관련되어있어서 비교적 설정 룰들이 간단한 편
• 예시

// .prettierrc.js

module.exports = {
  printWidth: 100, // printWidth default 80 => 100 으로 변경
  singleQuote: true, // "" => ''
  arrowParens: "avoid", // arrow function parameter가 하나일 경우 괄호 생략
};

• 참고자료

Prettier · Opinionated Code Formatter

5-2. ESLint 설정

• eslint 설정은 커스터마이징 할 수 있는 부분이 많고, 언어별(js, ts 등), 환경별(web, node, react 등) 세팅을 해줘야 하는 부분이 많아서 다소 복잡하다.
• 처음부터 모든 rule 하나하나 설정하는 것이 불필요하거나 불편하다고 판단되는 경우와 다른 사람들이 이미 정의해둔 config를 설치한 후 확장해서 사용할 수도 있다.
• eslint에서 기본적으로 제공되지 않는 특정 환경을 위한 rule들을 추가하고 싶을 경우에는 plugin을 이용할 수 있습니다.
• 예시

// .eslintrc

{
  "extends": ["react-app", "eslint:recommended"],
  "rules": {
    "no-var": "error", // var 금지
    "no-multiple-empty-lines": "error", // 여러 줄 공백 금지
    "no-console": ["error", { "allow": ["warn", "error", "info"] }], // console.log() 금지
    "eqeqeq": "error", // 일치 연산자 사용 필수
    "dot-notation": "error", // 가능하다면 dot notation 사용
    "no-unused-vars": "error" // 사용하지 않는 변수 금지
  }
}

• 참고자료

Rules - ESLint - Pluggable JavaScript Linter

Configuration Files - ESLint - Pluggable JavaScript Linter

 

6. Husky

6-1. 도입 배경

• eslint + prettier를 도입하면 끝이 아님
• 아무리 패키지를 설치하고, 룰을 설정해도 작업자가 사용을 안하면 효과가 없음
• 하지만 개인이 매번 확인해서 실행하는 것은 실수가 발생할 여지가 있으며 강제성이 없음

6-2. 문제 해결 방안

• 자동화를 통해서 신경쓰지 않아도 자동으로 적용이 되게하고 특정 상황에서 강제로 적용이 되게 하자
• commit된 코드는 무조건 formatting이 완료되어야 하고, push된 코드는 무조건 eslint가 pass된 상태에서 push가 되도록 자동화를 구축해야 함

6-3. 실행 방안

• git hook을 도입하다!
• git hook? git에서 특정 이벤트 발생하기 전,후로 특정 hook 동작을 실행할 수 있게 하는것 (ex. commit, push)
• git hook 설정은 까다롭고, 모든 팀원들이 사전에 repo를 클론받고 메뉴얼하게 사전 과정을 수행해야지만 hook이 실행됨을 보장할 수 있음
• 실수로라도 사전 과정을 시행하지 않는다면 hook이 실행되지 않음
• 그래서 사용해보자! husky

6-4. Husky

Husky - Git hooks

• git hook 설정을 도와주는 npm package
• 번거로운 git hook 설정이 편함 + npm install 과정에서 사전에 세팅해둔 git hook을 다 적용시킬 수 있어서 모든 팀원이 git hook 실행이 되도록 하기가 편함
• husky를 통해서 pre-commit, pre-push hook을 설정 가능함

6-5. Husky & Lint-Staged를 통한 Git Hook 적용

1. npm install husky --save-dev

2. (처음 husky 세팅하는 사람만 실행 필요) npx husky install

• npx husky install : husky에 등록된 hook을 실제 .git에 적용시키기 위한 스크립트
• add postinstall script in package.json
  - 이후에 clone 받아서 사용하는 사람들은 npm install후에 자동으로 husky install 이 될 수 있도록 하는 설정

// package.json

{
  "scripts": {
    "postinstall": "husky install"
  },
}

• scripts 설정

// package.json

{
  "scripts": {
    "postinstall": "husky install",
		"format": "prettier --cache --write .",
		"lint": "eslint --cache .",
  },
}

• add pre-commit, pre-push hook
  a. npx husky add .husky/pre-commit "npm run format"
  b. npx husky add .husky/pre-push "npm run lint"
  

6-6. 참고사항

• git hook에서 eslint 에러가 발견하면 실행중인 script가 종료되기에 이 rule에 대해서 error로 설정할 지 warn으로 설정할 지 잘 고려해야함
  • 예시)
    • 아래와 같이 되어있으면 console.log 코드가 있어도 푸쉬가 되지만
      • "no-console": ["warn", { "allow": ["warn", "error", "info"] }]
    • error로 설정할 경우 console.log가 하나라도 있으면 푸쉬가 안됨
      • "no-console": ["error", { "allow": ["warn", "error", "info"] }]
  • 참고사항)
    • 린트에서 warning도 엄격하게 하나도 허용하지 않으려면
    • eslint --max-warings=0 으로 옵션을 붙여서 스크립트를 실행하면 됨

// package.json

{
  "scripts": {
		"lint": "eslint --cache --max-warnings=0",
  },
}