Commitint, Commitizen, Standard Version 및 Husky를 SvelteKit 프로젝트에 추가

최근에 저는 코딩 스타일과 리포지토리 품질, 특히 커밋 메시지와 버전 관리를 조정하여 내부 SvelteKit 프로젝트를 개선하는 데 많은 시간을 보냈습니다.

이 게시물에서는 프로젝트에 Conventional Commits 및 SemVer 표준을 추가한 방법을 공유하고 commitlint, commitlizen, standard-version 및 husky 설정을 안내합니다.

기존 커밋 및 SemVer는 무엇입니까?

Here, I copy the summary from each website. You can find more via the link.

기존 커밋

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

커밋 메시지는 다음과 같이 구성되어야 합니다.

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

/* Example */
feat(landing): add register button and authentication

SemVer - 시맨틱 버전 관리

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes

2. MINOR version when you add functionality in a backward-compatible manner

3. PATCH version when you make backward-compatible bug fixes

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

기존 SvelteKit(또는 다른 JavaScript) 프로젝트에서 채택하는 방법은 무엇입니까?

You can find the demo repo here: conventional-commits-sveltekit.

커밋린트

먼저 커밋 메시지가 기존 커밋 형식을 충족하는지 확인하는 Linting 도구인 commitlint 를 설치합니다.

# Install commitlint cli and conventional config
pnpm add -D @commitlint/config-conventional @commitlint/cli

# Configure commitlint to use conventional config
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.cjs

Use .cjs instead of .js because "type": "module" is set in package.json in SvelteKit project.

이제 commitlint가 작동하는지 테스트해 보겠습니다(linting이 통과되면 프롬프트가 표시되지 않음).

🐶 허스키

husky 를 만들기 전에 커밋 메시지를 확인하기 위해 편리한 git 후크 도우미인 commitlint 와 함께 git commit 를 사용하는 것이 좋습니다.

Will add more git hooks later.

# Install husky
pnpm add -D husky

# Active hooks
pnpx husky install

# Add hook
npx husky add .husky/commit-msg 'pnpx --no -- commitlint --edit $1'

git commit를 만들어 봅시다.

husky would abort the commit if it didn't pass the commitlint

커미티즌

매번 유효한 커밋 메시지를 입력해야 한다면 그리 유쾌하지 않습니다.
commitizen는 커밋 시 필수 커밋 필드를 채우는 데 도움이 되는 CLI 도구입니다.

# Install commitizen, 
# @commitlint/cz-commitlint (adapter), and
# inquirer (peer dependency of @commitlint/cz-commitlint)
pnpm add -D commitizen @commitlint/cz-commitlint inquirer

커밋할 때 pnpm cz 대신 git commit를 사용하면 됩니다. 또는 package.json에 pnpm 스크립트를 추가하십시오.

...
  "scripts": {
    "commit": "cz"
  }

한번 해봅시다:

We use @commitlint/cz-commitlint as a commitizen adapter to ensure the commit adheres to the commit convention configured in commitlint.config.cjs.

표준 버전

커밋 메시지를 쉽게 생성하고 검증할 수 있도록 commitlint, husky 및 commitizen을 구성했습니다.

이제 standard-version 를 사용하여 버전 관리 및 변경 로그 생성을 자동화하는 방법을 살펴보겠습니다.

# Install standard-version
pnpm add -D standard-version

package.json에 pnpm 스크립트를 추가합니다.

...
  "scripts": {
    "release": "standard-version --no-verify" 
    // use --no-verify to skip git hooks we'll introduce later
  }

standard-version의 작동 방식은 다음과 같습니다.

1. Retrieve the current version of your repository by looking at packageFiles, falling back to the last git tag.
2. bump the version in bumpFiles based on your commits.
3. Generates a changelog based on your commits (uses conventional-changelog under the hood).
4. Creates a new commit including your bumpFiles and updated CHANGELOG.md.
5. Creates a new tag with the new version number.

해보자:

기본적으로 CHANGELOG.md 는 feat 또는 fix 에 속한 커밋만 표시하지만 모든 커밋을 내 변경 로그에 포함하고 이모티콘을 추가하는 것을 좋아합니다.

프로젝트 루트 폴더 아래에 .versionrc를 생성하여 사용자 정의할 수 있습니다. 내 설정은 다음과 같습니다.

{
  "types": [
    {
      "type": "feat",
      "section": "✨ Features"
    },
    {
      "type": "fix",
      "section": "🐛 Bug Fixes"
    },
    {
      "type": "chore",
      "hidden": false,
      "section": "🚚 Chores"
    },
    {
      "type": "docs",
      "hidden": false,
      "section": "📝 Documentation"
    },
    {
      "type": "style",
      "hidden": false,
      "section": "💄 Styling"
    },
    {
      "type": "refactor",
      "hidden": false,
      "section": "♻️ Code Refactoring"
    },
    {
      "type": "perf",
      "hidden": false,
      "section": "⚡️ Performance Improvements"
    },
    {
      "type": "test",
      "hidden": false,
      "section": "✅ Testing"
    }
  ]
}

You can see more options in Conventional Changelog Configuration Spec.

🐶 허스키 - 더 많은 git hooks

커밋과 태그를 푸시하기 전에 더 많은 git hook을 추가하여 코드 품질을 개선하는 것을 고려할 수 있습니다.
서식 지정, 린팅 및 테스트와 같습니다.

이미 "저장 시 포맷"을 설정했거나 린팅을 실행했거나 감시 모드에서 단위 테스트를 수행했을 수 있지만 이는 개인 취향입니다. 더 나은 코드 품질과 효율적인 공동 작업을 보장하기 위해 pre-commit 및 pre-push와 같은 git 후크를 추가하여 PR을 열기 전에 형식 지정, 린트 및 테스트를 수행할 수 있습니다.

아래에서는 SvelteKit 스켈레톤 프로젝트를 예로 들어 보겠습니다. Typescript, Prettier, ESLint 및 Playwright를 선택합니다.

먼저 pre-commit 단계에서 서식 지정 및 린팅을 추가합니다.

# Add pre-commit hook
npx husky add .husky/pre-commit 'pnpm format && pnpm lint && git add .'

두 번째(선택 사항), svelte-check 단계에서 pre-push를 추가합니다.

# Add pre-push hook
npx husky add .husky/pre-push 'pnpm check'

I didn't put playwright test here because I think it's better to do the e2e test in CI.
If you're using a test runner like jest, uvu, or vitest, you may consider running unit/ component tests in the pre-commit or pre-push stage.

주의 사항

git hooks는 묘책이 아닙니다. 동료는 특정 방식으로 여전히 "우회"할 수 있지만 팀과 함께 사용하고 조정하는 것이 좋습니다.

Some argue that "Run linting and testing in git hooks is just a drag on productivity and can't force anything. Why do this if we've already had them in CI? It's even useless if your tests didn't run in a production-like environment."

그것은 사실 일 수 있으며 팀과 초점에 따라 다릅니다.

DevOps에서 "Shift-Left"접근 방식을 생각하면서 어쨌든 사용합니다.

마무리

읽어주셔서 감사합니다! 🙌

귀하의 프로젝트에서 Conventional Commits 및 SemVer를 채택하는 단계를 살펴보았습니다.
또한 다양하고 시도해 볼 수 있습니다.

gitmoji을 시도하고 를 시도했지만 standard-version의 변경 로그 생성과 호환되지 않기 때문에 이 문서의 설정을 사용하게 됩니다(Ref: Issue #859 )

우리 팀과 저는 여전히 첫 번째 CI/CD 파이프라인을 작업하고 있으며 이 기사는 워크플로를 개선하기 위한 첫 번째 단계입니다.

여러분의 생각과 경험을 친절하게 공유해주세요. 당신에게서 배우는 것을 좋아합니다!

Twitter에서 저를 찾을 수 있습니다:

유용한 리소스:

(지혜가 충만)

Master the Code Review by Curtis Einsmann (아직 끝나지 않았지만 내용이 너무 좋아서 여기에 공유합니다!)