Prettier, ESLint로 협업 강화하기 글에 이어서 자동화를 시켜보자.
저번 글에서 설명한 것처럼 사용하지 않는 변수와 같은 '코드 품질' 검사는 ESLint에게 맡기고 '일관된 코드 스타일', '가독성'은 Prettier가 담당을 했다. 둘의 장점을 합쳐 통합까지 완료를 하고보니 매번 개발자가 명령어를 실행하기엔 비효율적이다. 이 효과를 제대로 보려면 자동화가 필요하다.
자동화를 하는 방법은 두 가지로 나뉜다.
- 깃 훅(Git Hooks)을 사용하는 방법
- VS Code extension을 사용하는 방법
Git Hooks
깃(git)은 어떤 이벤트가 생겼을 때 자동으로 특정 스크립트를 실행하도록 할 수 있다. 다시 말해 깃 훅은 명령어 실행 전후에 특정 스크립트를 실행하게 만들 수가 있다. 이걸 좀 더 쉽게 할 수 있는 도구는 없을까?
'husky'를 함께 사용하면 수월하게 깃 훅을 사용할 수 있다.
npm install husky --save-dev
v5+부터는 Git Hook을 자동으로 설치하지 않기 때문에 훅을 설치 해야한다.
package.json 스크립트에 "prepare": "husky install"을 추가하고, 설치하는 명령어는 다음과 같다.
npm set-script prepare "husky install"
npm run prepare
이제 간단하게 커밋 전에 실행되는 훅을 추가해보자.
npx husky add .husky/pre-commit "echo 'Hello husky'"
git add .husky/pre-commit
그리고 커밋을 해보면 커밋 전 메시지가 출력되는 것을 볼 수 있다.
이걸 통해서 커밋 직전에 린트를 수행하게 만들 수 있다. add가 아닌 set으로 기존에 있던 스크립트를 변경해보자. (set으로 변경할 시 기존에 add된 스크립트들은 모두 제거된다.)
npx husky set .husky/pre-commit "npm run lint"
이렇게 설정 후 커밋을 해보면 husky에 의해 커밋 직전 린트가 수행되며, 에러 발견 시 커밋은 취소된다. 이렇게 린트에 통과 되어야만 코드가 커밋되도록 설정하여 협업 시, 코드 품질과 코드 컨벤션을 지킬 수 있다.
lint-staged
이런 설정들을 첫 프로젝트부터 도입을 했다면 문제가 없지만 중간에 도입을 했다면 어떨까? 특히 전체 파일에 적용을 했다고 생각해보자. 자잘한 경고부터 심각한 경고까지 수정 사항이 여러 곳에서 계속해서 나오게 될 것이다. 개발 이슈와는 상관 없는 파일들까지 갈아엎고 수정하며 'lint 수정'과 같은 무의미한 커밋을 날려야 한다.
또한, 코드가 점점 많아진다면 커밋할 때마다 모든 파일을 린트로 실행하기 때문에 커밋이 느려질 수도 있다.
따라서 git에 staged된, 즉 변경된(스테이징된) 파일만 린트로 검사해주는 도구가 바로 'lint-staged'이다.
npm install --save-dev lint-staged
.lintstagedrc 파일을 생성해서 설정해도 되지만 이번엔 간단하게 package.json에 추가했다.
// package.json 📂
// .js 파일만 린트로 검사
{
"lint-staged": {
"*.js": "npm run lint"
}
}
설정 후 pre-commit도 "lint-staged"를 실행하도록 변경한다.
npx husky set .husky/pre-commit "npx lint-staged"
이제 커밋을 하면 모든 파일을 검사하는 것이 아닌 변경되거나 추가된 파일만 검사하게 된다.
VS Code extension
커밋까지 갈 필요도 없이 코딩할 때 바로 바로 검사하는 방법도 존재한다. 저번 글에서 Prettier 규칙을 ESLint에 통합했기 때문에 ESLint extension만 설치하면 된다.
설치 후에 설정 파일로 가서 해당 extension을 활성화 시켜준다.
// settings.json 📂
{
"eslint.enable": true
}
이렇게 설정을 해주면 개발 중에 자동으로 코드를 감지하고 문제를 알려준다.
설정 옵션 중에 저장 시 자동으로 코드를 고쳐주는 것도 존재한다.
// settings.json 📂
{
"eslint.enable": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
}
}
마무리
개발자마다 코드 스타일이 다른 것은 당연하다고 생각한다. 각자 다른 환경, 강의, 배우는 시기 등으로 달라질 수 있다. 하지만 이것이 협업 시엔 꽤 크게 작용할 수 있다고 생각하기 때문에 이렇게 정리를 해봤다. 나는 팀에서의 적절한 규칙은 언제나 환영이다. 아직 사내에서 협업을 시작하진 않았지만 짧게 협업 경험을 해봤기 때문에 더욱 필요성을 느끼게 되었다. 간단한 코드 스타일을 변경했을 뿐인데 커밋을 해야한다거나, 자잘하게 시간을 쓰게 만든다.
따라서 이런 적절한 규칙은 필요하다고 생각했고 충분히 배우고, 적용해볼만 하다.
참고
린트(ESLint)와 프리티어(Prettier)로 협업 환경 세팅하기 - 김정환
husky - 공식 웹사이트
Husky 사용할 때 주의! - 코드쓰는사람
lint-staged - npm
lint-staged로 eslint 세상 편하게 자동화하기 - huskyhoochu
Git맞춤 - Git Hooks
'JavaScript' 카테고리의 다른 글
[JavaScript] 디바운싱과 쓰로틀링 (2) | 2022.06.10 |
---|---|
[JS] switch 사용법(feat.타입스크립트) (0) | 2022.03.27 |
Prettier, ESLint로 협업 강화하기 (0) | 2021.12.24 |
웹팩(Webpack) 이해하기 - 개발 서버 (0) | 2021.11.22 |
웹팩(Webpack) 이해하기 (0) | 2021.11.16 |