auth-frontend dans jobPipeline¶

Date : 2026-07-02

Contexte¶

Le module Auth/2FA/Sessions de ProjetESM a été extrait en deux packages npm privés locaux réutilisables : - @kanmaber/auth-backend — /home/kanmaber/projets/Shared/packages/auth-backend/ - @kanmaber/auth-frontend — /home/kanmaber/projets/Shared/packages/auth-frontend/

Ce document rapporte le résultat d'un test d'intégration réel de ces deux packages dans jobPipeline, pour valider (ou non) qu'ils sont réutilisables « en état » dans un projet différent de ProjetESM.

Backend — ✅ validé sans friction¶

@kanmaber/auth-backend ajouté en dépendance file:../../Shared/packages/auth-backend dans jobPipeline/BackEnd/package.json.

npm install : OK, résout sans conflit de peer dependencies (@prisma/client ^5, express ^5 déjà alignés avec jobPipeline).
npm run typecheck : OK, aucune régression sur le code existant de jobPipeline, et un import de test (AuthModule, AuthModuleController, DIContainer, IHttpContext) résout correctement.
Smoke test runtime (jobPipeline/BackEnd/scripts/smoke-test-auth-package.mjs) : AuthModule s'initialise avec 34 use cases, 9 repositories, 6 services, 36 controllers, sans DB réelle requise. AuthModuleController accepte bien la structure de contrôleurs produite.

Point non résolu : jobPipeline/BackEnd/prisma/schema.prisma a déjà son propre modèle Utilisateur (email/motDePasse/refreshToken simple, sans 2FA ni sessions ni audit). Le package utilise son propre @prisma/client généré depuis son propre schéma, donc aucune collision ne s'est manifestée lors de ce test (pas de DB réelle sollicitée). Mais pour connecter réellement AuthModule à la base de données de jobPipeline, il faudra fusionner auth-backend/prisma/auth.prisma.fragment dans le schema.prisma de jobPipeline — ce qui entrera en collision avec le modèle Utilisateur existant (renommage ou fusion de champs à décider).

Frontend — ⚠️ installe et typecheck, mais risque architectural identifié¶

@kanmaber/auth-frontend ajouté en dépendance file:../../Shared/packages/auth-frontend dans jobPipeline/FrontEnd/package.json.

npm install : OK, aucune erreur bloquante.
npm run typecheck (avec un import de test useAuth, LoginPage, configureAuthModule, container) : OK.
npm run build (vite) : échoue, mais pour une raison indépendante du package — index.html référence /src/main.tsx qui n'existe pas encore (jobPipeline n'a pas de frontend scaffoldé, src/ est quasiment vide).

Risque concret découvert : npm ls révèle que react-router-dom et zustand sont installés en double :

Paquet	Version jobPipeline (racine)	Version imbriquée dans le package
react-router-dom	7.18.0	6.30.4
zustand	5.0.14	4.5.7
lucide-react	0.488.0	1.23.0
axios	absent au niveau racine	1.18.1 (imbriqué)

Les composants du package qui utilisent useNavigate/Link (LoginPage, RegisterPage, ResetPasswordPage, TwoFactorPage, VerifyEmailPage, UserMenu) référenceraient l'instance react-router-dom imbriquée (v6), différente de celle du <BrowserRouter> que jobPipeline monterait avec sa propre v7 installée à la racine — schéma classique de « doublon de paquet React » qui casse le contexte Router à l'exécution (useNavigate() appelé hors contexte lève une erreur).

Non vérifié par un rendu réel : impossible de le prouver en conditions réelles à ce stade car jobPipeline n'a pas encore de frontend construit (pas de main.tsx, pas d'arbre de composants monté).

Recommandations avant intégration réelle¶

Backend : décider comment fusionner le modèle Utilisateur (renommer celui de jobPipeline, ou migrer ses données vers le modèle du package) avant de câbler AuthModule sur la vraie base.
Frontend : soit élargir les peerDependencies d'auth-frontend pour accepter react-router-dom ^6 || ^7 et zustand ^4 || ^5 après vérification de compatibilité réelle des hooks utilisés, soit aligner jobPipeline sur les versions actuellement supportées par le package. Ne pas supposer que ça fonctionne tant qu'un rendu réel n'a pas été testé avec le Router de jobPipeline effectivement monté.

État laissé dans jobPipeline après ce test¶

jobPipeline/BackEnd/package.json et jobPipeline/FrontEnd/package.json modifiés (ajout des deux dépendances file:).
node_modules installés dans les deux sous-projets.
jobPipeline/BackEnd/scripts/smoke-test-auth-package.mjs créé (script de vérification, peut être relancé avec node scripts/smoke-test-auth-package.mjs).
jobPipeline n'a pas de dépôt git à ce jour — pas de filet de sécurité pour ces changements.