SolitTkitプロジェクトへのコミットメント、commitizen、標準バージョン、およびハスキーを加えます

最近、コーディングスタイルとレポ品質、特にコミットメッセージとバージョン管理を合わせて、私たちの内部のSveletKitプロジェクトを改善する多くの時間を費やしました.
このポストでは、私は私が我々のプロジェクトに従来のコミットとsemver標準を加えた方法を共有して、コミットメント、Commitlizen、標準バージョンとハスキーのセットアップを通してあなたを歩きます.

従来のコミットと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.

委託する

まず、インストール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.

では、commit lintが動作しているかどうかを調べましょう.

🐶 ハスキー

使用することをお勧めしますhusky with commitlint , 便利なgitフックヘルパー、任意の前にコミットメッセージをチェックする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 コミット時.またはPNPMスクリプトをpackage.json :

...
  "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、およびComchitizenを設定し、コミットメッセージを簡単に作成し、検証します.
では、VersioningとChangeLogの生成を自動化する方法を見てみましょうstandard-version .

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

Pnpmスクリプトをあなたのpackage.json .

...
  "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 or fix , しかし、私はchangelogであらゆるコミットを持っていて、Emojisを加えたいです.
我々はそれを作成することによってカスタマイズすることができます.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フック

コミットとタグを押す前に、我々のコード品質を改善するために、より多くのGitフックを加えることを考慮することができます.
書式設定、リンギング、およびテストのように.
たぶん、あなたは既に“保存時にフォーマット”を設定し、ウォッチモードを実行するか、またはユニットモードのテストを実行しているが、それは個人的な好みです.より良いコードの品質と効率的なコラボレーションを確保するために、我々はgitフックを追加することができますpre-commit , and pre-push Printを開く前にフォーマット、LINT、およびテストする.
以下にSvelteKitスケルトンプロジェクトを例に挙げます.私はタイプスクリプト、きれいな、エスニック、脚本を選択します.
まず、書式設定とリンギングを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の“シフト左”アプローチについて考えながらそれをとにかく使用します.

包む

あなたの読書をありがとう!🙌
私たちはあなたのプロジェクトで従来のコミットとsemverを採用する手順を歩いてきました.
また、多くの異なるし、試すことができます.
やってみたgitmoji そして、それに続くが、この記事の設定を使用して終了しますstandard-version 参照).Issue #859 )
私のチームと私はまだ最初のCI/CDパイプラインに取り組んでいます.
親切にあなたの考えと経験を共有してください.あなたから学ぶ愛!
あなたはTwitterで私を見つけることができます

有用なリソース

(知恵に満ちた)
Master the Code Review カーチスEinsmann(私はまだ終わっていません、しかし、内容はとても大きいので、私はそれをここで共有する必要があります!)