Skip to main content

Husky

On ne parlera pas dans cette partie de la race de chien mais bien de l'outil pour ajouter des hooks dans le le process de développement GIT !

Conventional Commits​

Les "Conventional Commits" (commits conventionnels) constituent une spécification pour ajouter une signification sémantique aux messages de commit. Cette convention standardisée facilite :

  • La génération automatique de changelogs
  • La détermination automatique de versions sémantiques (SemVer)
  • La communication claire des changements aux coéquipiers et utilisateurs
  • Le déclenchement de processus de build et de déploiement appropriés

Structure d'un Conventional Commit​

Un message de commit conventionnel a la structure suivante :

<type>[scope optional]: <description>

[optional body]

[optional footer(s)]

Type​

Le type définit la nature du changement et fait partie des catégories suivantes :

  • feat : Ajout d'une nouvelle fonctionnalité
  • fix : Correction d'un bug
  • docs : Modification de la documentation
  • style : Changements qui n'affectent pas le sens du code (espaces, formatage, etc.)
  • refactor : Changement de code qui ne corrige pas un bug et n'ajoute pas de fonctionnalité
  • perf : Amélioration des performances
  • test : Ajout ou correction de tests
  • build : Changements qui affectent le système de build ou les dépendances externes
  • ci : Changements dans la configuration CI ou les scripts
  • chore : Autres changements qui ne modifient pas les fichiers src ou test
  • revert : Annulation d'un commit précédent

Scope​

Le scope est optionnel et indique la partie du code affectée par le changement (par exemple, auth, api, db).

Description​

Une description concise du changement au présent. Ne pas capitaliser la première lettre et ne pas mettre de point à la fin.

Body​

Le corps est optionnel et fournit des détails supplémentaires sur le changement. Il doit commencer par une ligne vide après la description.

Le footer est optionnel et peut contenir des références à des issues, des notes sur les changements non rétrocompatibles (breaking changes), etc.

Exemples de Conventional Commits​

feat(auth): ajouter la fonction de réinitialisation de mot de passe

Cette fonctionnalité permet aux utilisateurs de réinitialiser leur mot de passe via un email de confirmation.

Closes #123
fix: corriger le bug d'authentification lors de la connexion avec Google
docs: maj de la documentation de l'API REST
feat: ajouter la fonction de recherche avancée

BREAKING CHANGE: L'ancienne API de recherche n'est plus compatible.

Husky​

Husky est un outil qui permet d'utiliser des Git hooks plus facilement. Les Git hooks sont des scripts qui s'exécutent automatiquement lorsque certaines actions Git sont effectuées.

Que sont les Git hooks ?​

Les Git hooks sont des scripts qui s'exécutent avant ou après des événements Git comme commit, push, etc. Ils permettent d'automatiser des tâches comme :

  • Vérifier le formatage du code avant un commit
  • Exécuter des tests avant un push
  • Valider la syntaxe des messages de commit

Installation de Husky​

npm install husky --save-dev
npx husky install
npm pkg set scripts.prepare="husky install"

La commande npm pkg set scripts.prepare="husky install" ajoute un script prepare à votre package.json. Ce script s'exécute automatiquement après npm install, ce qui garantit que Husky est configuré pour tous les membres de l'équipe.

Création d'un hook pre-commit​

Le hook pre-commit s'exécute avant qu'un commit ne soit finalisé. C'est l'endroit idéal pour vérifier la qualité du code.

npx husky add .husky/pre-commit "npm run lint && npm run test"

Cette commande crée un fichier .husky/pre-commit qui exécute le linter et les tests avant chaque commit. Si l'une de ces commandes échoue, le commit est annulé.

Installation et configuration de commitlint​

Pour vérifier que les messages de commit suivent la convention des Conventional Commits, nous pouvons utiliser commitlint :

npm install @commitlint/cli @commitlint/config-conventional --save-dev

Créez un fichier commitlint.config.js à la racine de votre projet :

module.exports = {
   extends: ['@commitlint/config-conventional'],
};

Ajoutez un hook commit-msg pour valider le message de commit :

npx husky add .husky/commit-msg "npx --no -- commitlint --edit $1"

Configuration de lint-staged​

lint-staged permet d'exécuter des commandes sur les fichiers qui sont sur le point d'être commités, au lieu de vérifier l'ensemble du projet à chaque fois.

npm install lint-staged --save-dev

Ajoutez une configuration lint-staged à votre package.json :

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

Modifiez votre hook pre-commit pour utiliser lint-staged :

npx husky add .husky/pre-commit "npx lint-staged"

Utilisation de Commitizen (optionnel)​

Commitizen est un outil qui guide les développeurs pour créer des messages de commit conformes à la convention.

npm install commitizen cz-conventional-changelog --save-dev

Ajoutez la configuration suivante à votre package.json :

{
   "scripts": {
      "commit": "cz"
   },
   "config": {
      "commitizen": {
         "path": "cz-conventional-changelog"
      }
   }
}

Maintenant, au lieu d'utiliser git commit, vous pouvez utiliser npm run commit pour être guidé dans la création d'un message de commit conventionnel.

Flux de travail complet​

Voici comment fonctionne le flux de travail complet avec Husky, commitlint et lint-staged :

  1. Le développeur apporte des modifications au code et les ajoute à l'index avec git add.
  2. Le développeur lance un commit avec git commit ou npm run commit (si Commitizen est configuré).
  3. Le hook pre-commit s'exécute :
    • lint-staged exécute ESLint et Prettier sur les fichiers modifiés
    • Les tests sont exécutés (si configuré)
  4. Si le pre-commit réussit, le message de commit est validé par commitlint via le hook commit-msg.
  5. Si le message est conforme, le commit est créé.

Avantages de cette approche​

L'utilisation de Conventional Commits avec Husky présente plusieurs avantages :

  • Histoire de projet plus lisible : Les messages de commit standardisés facilitent la compréhension de l'historique du projet.
  • Génération automatique de changelogs : Les outils comme semantic-release peuvent générer automatiquement des notes de version basées sur les messages de commit.
  • Versioning sémantique automatique : Le type de changement (feat, fix, etc.) peut déterminer automatiquement la prochaine version.
  • Qualité du code améliorée : Les vérifications pré-commit garantissent que seul le code de qualité est commité.
  • Réduction des erreurs : Les vérifications automatiques réduisent le risque d'erreurs humaines.

En standardisant les messages de commit et en automatisant les vérifications, vous simplifiez la collaboration et améliorez la qualité globale de votre projet.