2.2 KiB
2.2 KiB
Contribuer à Ben-to
Workflow
- Ouvrir ou référencer une issue GitHub (comportement attendu, contexte, critères d’acceptation).
- Créer une branche depuis
main:feat/issue-123-courte-description,fix/issue-123-…, etc. - Implémenter en respectant la structure feature-first (
packages/features/*,packages/shared/*) et les règles du dépôt (.cursor/rules/). - Scénarios Gherkin (
specs/features/*.feature) : tout tag@int-*doit apparaître dans un fichier*.int.test.tscorrespondant (voirnpm run check:gherkin-scenarios). - Imports explicites : pas de fichier barrel
packages/**/src/index.ts; utiliser les sous-chemins documentés dans lespackage.jsonexportset les alias Vite (@ben-to/.../domain, etc.). - Avant la PR :
npm run check:qualityetnpm run test:ci. - Issue GitHub : la laisser ouverte jusqu’au merge de la PR. Inclure dans le message de commit (recommandé, dernière ligne)
Closes #N/Fixes #Npour que GitHub ferme l’issue automatiquement au merge ; éviter de fermer l’issue manuellement avant la fusion.
Hook pre-commit (tests unitaires)
Après npm install, Husky installe un hook qui exécute vitest related sur les fichiers .ts / .tsx stagés (projet unit uniquement).
Contournement exceptionnel (hotfix documenté en PR) : git commit --no-verify.
Qualité et couverture
- Les seuils de couverture Vitest s’appliquent aux sources sous
packages/features/**etpackages/shared/**(voirvitest.config.ts). Le front web est couvert par les e2e, Axe et Lighthouse. - La CI publie un commentaire de synthèse sur les PR (couverture, audit npm, Axe, Lighthouse, timings navigation).
GitHub
- Activez Code scanning avec CodeQL si vous voulez les résultats SARIF dans l’onglet Sécurité ; puis retirez
upload: falsedans.github/workflows/security.yml(voir docs/CODE_SCANNING.md). - Protégez la branche
main: CI obligatoire, revues si vous travaillez en équipe.
Mobile Android
Les commandes mobile:* se lancent depuis la racine du monorepo (voir README.md). La CI exécute assembleDebug pour détecter les régressions Gradle/Capacitor.