Husky 및 Lint-staged로 다이빙

지난 주에 나는 ESLint과 여러 기여자들 사이에서 일관성 있는 프로젝트를 유지하기 위한 유용성에 대해 이야기했습니다. 해당 게시물을 읽지 않았다면 이 게시물을 읽기 전에 읽어보는 것이 좋습니다.

오늘은 ESLint를 자동으로 실행하여 프로젝트의 주요 분기가 항상 특정 규칙 집합을 따르도록 하는 데 중점을 둘 것입니다.

보푸라기 단계

첫 번째로 이야기할 도구는 lint-staged 입니다. Lint-staged는 package.json 파일에 구성되어 있습니다.

{
  "lint-staged": {
    "*.js": "eslint --fix"
  }
}

위의 예에서 볼 수 있듯이 glob 패턴을 사용하여 lint-staged에 실행할 파일을 알릴 수 있습니다. 또한 lint-staged에 해당 파일에 대해 실행할 명령을 줄 수 있습니다. 많은 경우에 Lint-staged가 지원하는 둘 이상의 명령이 필요할 것입니다. 이 경우 ESLint 및 prettier 을 실행합니다.

{
  "lint-staged": {
    "*.js": ["eslint", "prettier --write"]
  }
}

그렇다면 Lint-staged는 어떻게 작동합니까? "스테이징된"파일, 따라서 이름에서 작동하도록 특별히 설계되었습니다. 이는 변경하거나 생성했지만 아직 프로젝트에 커밋하지 않은 파일을 의미합니다. 준비된 파일에 대한 작업은 주어진 시간에 린트해야 하는 파일 수를 제한하고 워크플로를 더 빠르게 만듭니다. 구성한 명령은 "사전 커밋"을 실행합니다. 프로젝트에 파일을 커밋하려고 하면 터미널에서 ESLint가 실행되는 것을 볼 수 있습니다. 완료되면 코드를 커밋할 수 있기 전에 수정해야 하는 linting 오류가 있거나 성공적으로 커밋했을 수 있습니다.

그러나 당신이 깨닫지 못할 수도 있는 것은 보푸라기 단계가 내부에서 작동하는 유일한 도구가 아니라는 것입니다. Lint-staged는 husky 이라는 다른 도구와 함께 작동하도록 설계되었습니다.

에스키모 개의

당신은 전에 눈치채지 못한 채 허스키를 만났을 수도 있습니다. 수년 동안 package.json 파일에서 몇 줄의 코드를 통해 구성되었습니다. 이 같은.

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

그러나 최신 버전의 husky v6에서는 이러한 접근 방식이 변경되었습니다. 이제 husky는 해당하는 워크플로 단계와 일치하는 파일 이름을 가진 고유한 bash 파일을 사용합니다. "사전 커밋". 운 좋게도 이것을 직접 설정할 필요가 없으며 husky에는 이를 수행할 수 있는 멋진 CLI 명령이 있습니다.

npx husky-init && npm install
npx husky add .husky/pre-commit "npm test"

명령의 첫 번째 줄은 모든 동료가 파일 커밋을 시도하기 전에 컴퓨터에 husky를 설치하도록 하는 일회성 초기화 스크립트입니다.

두 번째 줄은 pre-commit 디렉토리 안에 .husky 파일을 생성합니다. 파일을 보면 초기화한 명령보다 먼저 husky.sh 스크립트를 실행하고 있음을 알 수 있습니다. 이것은 기술적으로 제거할 수 있지만 유지하는 것이 좋습니다. 스크립트는 검사를 우회하는 --no-verify 플래그의 사용을 포함하여 몇 가지를 허용합니다.

디렉토리와 관련 파일을 초기화하면 원하는 명령을 추가할 수 있습니다. 제 경우에는 npm test 를 npm lint-staged 로 바꿨습니다.

미리 푸시

pre-commit 워크플로는 다소 허스키한 행복한 경로입니다. 그러나 프로젝트가 커밋 시 린트를 원하지 않고 개발자가 변경 사항을 브랜치로 푸시하려고 할 때 린트를 선호한다면 어떻게 될까요?
.husky/pre-push 파일을 만들고 lint-staged를 실행하고 싶지만 작동하지 않습니다. pre-push husky 워크플로는 정확하지만 해당 지점에서 lint-staged를 실행하면 일치하는 파일이 0개 나타납니다. 커밋된 파일이 더 이상 준비되지 않기 때문에 약간 혼란스러웠지만 이것은 의미가 있습니다. 대신 몇 가지 옵션이 있습니다.

모든 파일에 대해 ESLint를 실행합니다. eslint '*.js'

비교 main : eslint --no-error-on-unmatched-pattern $(git diff main... --name-only --- '*.js')

이것은 diff 명령의 한 예이며 프로젝트에 따라 많은 고려 사항이 있습니다.

다음 단계 및 CI

git 워크플로의 일부로 ESLint, 더 예쁜 또는 테스트를 실행하는 것은 빠르게 실패하는 데 도움이 되기 때문에 중요합니다. 그러나 CI 검사를 대체하지는 않습니다. 일반적으로 아무 문제도 발생하지 않도록 두 환경에서 이러한 명령을 실행하려고 할 것입니다.

그러나 이러한 도구는 모두 더 깨끗하고 일관된 프로덕션 코드베이스를 보장하는 데 도움이 됩니다. 장기적으로 이것은 모든 프로젝트에 있어 큰 승리입니다.