Stack, bonnes pratiques & mémo technique
Stack (rappel)
| Couche | Techno |
|---|---|
| UI | React 18, Tailwind 3, lucide-react |
| Build | Vite 5 |
| Backend | Supabase (PostgreSQL + Auth + Storage) |
| Hébergement | Netlify (SPA + redirects) |
| Config | VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY |
Bonnes pratiques à adopter
Git & collaboration
- Une branche par sujet :
git switch -c feat/export-comptable. Jamais surmain. - Conventional Commits :
type(scope): résumé(cf. 02-conventions §6). - PR + revue avant merge ; protéger
main. - Ne jamais committer de secret ; garder
.envhors du dépôt (.gitignore).
Code
- Style existant : composants fonctionnels, Tailwind inline, français dans l'UI.
- Extraire la logique métier (paie, alertes, périmètres) hors des composants pour la tester.
- Uniformiser les dates (tout en local) - bannir
toISOString().slice(0,10)pour les dates « calendaires ». - Toute nouvelle table/colonne → migration SQL versionnée dans
supabase-*.sql.
Base & sécurité
- Écrire des policies RLS par rôle/périmètre (ne pas se reposer sur l'UI).
- Utiliser des Edge Functions pour les opérations de confiance.
- Buckets privés + URLs signées (déjà fait pour
employee-docs).
Qualité
npm run builddoit passer avant tout commit.- Ajouter ESLint + Prettier, puis Vitest, puis CI GitHub Actions.
Pièges connus (spécifiques à ce repo)
| Piège | Détail | Parade |
|---|---|---|
| Dates UTC vs local | computeHoursFromPlanning et alerts utilisent l'UTC |
Centraliser dans lib/dates.js (local) |
| RLS ouverte | Tout authentifié = accès total | Durcir la RLS (P0) |
| Schéma non versionné | 3 tables + colonnes absentes des migrations | Extraire le DDL réel |
select("*") global |
Charge tout, sans périmètre | Requêtes ciblées + RLS |
| Ville par mots-clés | CITY_CONFIG fragile |
Normaliser (table/colonne ville) |
| Semaines/mois ≈ jours/7 | Approximation paie | Valider avec le comptable |
