feat: Gestion des inscriptions [#1] feat(frontend): Création des vues pour le paramétrage de l'école [#2] feat: Gestion du login [#6] fix: Correction lors de la migration des modèle [#8] feat: Révision du menu principal [#9] feat: Ajout d'un footer [#10] feat: Création des dockers compose pour les environnements de développement et de production [#12] doc(ci): Mise en place de Husky et d'un suivi de version automatique [#14]
4.3 KiB
1. Code Guidelines pour N3WT-SCHOOL
Back-end (Python Django)
-
Style : Adoptez PEP 8 (https://peps.python.org/pep-0008/) (style standard pour Python) avec des ajustements pour vos besoins spécifiques. Utilisez Black pour le formatage automatique.
-
Documentation : Utilisez des docstrings conformes à la convention SWAGGER (https://www.geeksforgeeks.org/python-swagger-annotations-for-api-documentation/).
-
Imports :
- Regroupez par sections (bibliothèques standard, dépendances externes, imports internes).
- Utilisez des imports explicites, pas de wildcard (
from module import *).
-
Nom des variables : Suivez un style snake_case pour les noms de variables et de fonctions.
-
Path patterns: **/*.py
Front-end (Next.js avec React et TailwindCSS)
- Structure des fichiers :
- Un composant = un fichier, placé dans
/componentsou/pagesselon le cas. - Utilisez des hooks personnalisés pour éviter de dupliquer la logique.
- Un composant = un fichier, placé dans
- Style :
- Utilisez TailwindCSS avec des classes utilitaires dans le fichier JSX directement.
- Favorisez une approche mobile-first.
- Nom des fichiers :
- Composants React : PascalCase (e.g.,
StudentForm.jsx). - Variables et fonctions : camelCase.
- Composants React : PascalCase (e.g.,
- Linting :
- Activez ESLint avec des règles adaptées à Next.js.
- Ajoutez Prettier pour formater automatiquement le code.
- Commentaires : Expliquez uniquement la logique complexe dans des commentaires succincts.
Path patterns: **/.ts, **/.js, **/.jsx, **/.tsx
2. Commit Guidelines (Conventionnel)
Les messages de commits se basent sur Conventional Commits (https://www.conventionalcommits.org/en/v1.0.0/) , pour une meilleure gestion des versions et une génération automatique du changelog.
Format standard :
<type>(<scope>): <description> [#<ticket-id>]
-
Types autorisés :
feat: Nouvelle fonctionnalité.fix: Correction d’un bug.docs: Modifications liées à la documentation.style: Mise en forme du code (pas de changements fonctionnels).refactor: Refactorisation sans ajout de fonctionnalités ni correction de bugs.test: Ajout ou modification de tests.chore: Maintenance ou tâches diverses (ex. mise à jour des dépendances).
-
Scope (optionnel) : Précisez une partie spécifique du projet (
backend,frontend,API, etc.). -
Exemples :
feat(frontend): ajout de la gestion des utilisateurs dans le dashboard [#1] fix(backend): correction du bug lié à l'authentification JWT [#1] docs: mise à jour du README avec les nouvelles instructions d’installation [#2] -
Template de commit message
Dans le fichier .gitmessage.txt ajoutez le contenue suivant:
<type>(<scope>): <description> [#<ticket-id>]
# Types:
# - feat: Nouvelle fonctionnalité
# - fix: Correction de bug
# - docs: Documentation
# - style: Changements esthétiques
# - refactor: Refactorisation
# - test: Ajout/modification de tests
# - chore: Tâches diverses (e.g., mise à jour des dépendances)
#
# Scope: Optionnel (ex. backend, frontend, API)
#
# Ticket ID: Référence à un ticket ou une issue (ex. [#PROJ-123])
Ajoutez cette configuration à votre fichier global .gitconfig :
git config commit.template .gitmessage.txt
Lors de chaque commit, le modèle s’affichera automatiquement.
Automatisation avec Commitlint
Vous pouvez configurer Commitlint pour forcer l'inclusion d'un ID de ticket dans chaque message de commit.
Étape 1 : Installer Commitlint et Husky
npm install --save-dev @commitlint/{config-conventional,cli}
npm install --save-dev husky
npx husky install
Étape 2 : Configurer Commitlint
Créez un fichier commitlint.config.js :
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'subject-case': [0, 'always'],
'scope-enum': [2, 'always', ['frontend', 'backend', 'api', 'docs', 'ci', 'devops']],
'type-enum': [
2,
'always',
['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']
]
}
};
Étape 3 : Configurer Husky pour le hook pre-commit
Ajoutez un hook avec Husky pour vérifier les commits :
npx husky add .husky/commit-msg "npx --no-install commitlint --edit $1"