auth-frontend via tarball npm¶

Date : 2026-07-03 (suite de 20260702_1814_test-integration-auth-packages.md)

Contexte¶

Le premier test d'intégration (2026-07-02) avait été fait via une dépendance file:../../Shared/packages/... (symlink npm). On a découvert par la suite, en creusant une question sur react-router-dom, que file: ne garantit pas une instance de module unique même à version strictement identique — vérifié via require.resolve() : deux chemins physiquement différents.

Ce document reprend le même test, cette fois via une vraie installation par tarball (npm pack + référence au .tgz dans package.json), qui est la seule méthode qui déduplique correctement (comme un vrai npm install depuis un registre).

Méthode¶

// jobPipeline/BackEnd/package.json
"@kanmaber/auth-backend": "file:../../Shared/packages/auth-backend/kanmaber-auth-backend-1.0.0.tgz"

// jobPipeline/FrontEnd/package.json
"@kanmaber/auth-frontend": "file:../../Shared/packages/auth-frontend/kanmaber-auth-frontend-1.0.0.tgz"

(file: pointant vers un fichier .tgz — et non un dossier — déclenche une vraie extraction/copie par npm, pas un symlink.)

Résultat 1 — react-router-dom et zustand : dédupliqués, confirmé¶

npm ls react-router-dom zustand
├── react-router-dom@7.18.1 deduped
└── zustand@5.0.14 deduped

Confirmé par require.resolve() des deux côtés (jobPipeline et le package) : même fichier physique pour les deux librairies. Le risque de contexte Router dupliqué identifié la veille est bien résolu par cette méthode d'installation — chose que file: ne garantissait pas.

Résultat 2 — conflits de peer dependencies révélés (masqués par `file:`)¶

L'installation stricte (tarball) a bloqué immédiatement sur @hookform/resolvers : jobPipeline a ^5.0.1, le package exige ^3.3.0 (écart de version majeure jamais remonté avec file:, qui est plus permissif). lucide-react a le même type d'écart (jobPipeline 0.488.0 vs peer ^1.7.0). Contournés avec --legacy-peer-deps pour ce test — pas une solution durable, juste pour vérifier le reste.

Conclusion pratique : file: masque aussi les conflits de peer dependencies, pas seulement le problème de déduplication de modules. Une vraie validation d'intégration doit toujours passer par un tarball, jamais par file: sur un dossier.

Résultat 3 — Prisma : le vrai blocage devient visible¶

Avec le dédup correct, @prisma/client devient lui aussi une instance partagée entre jobPipeline et le package (même mécanisme que react-router-dom). Concrètement :

const { PrismaClient } = require('@prisma/client');
const p = new PrismaClient();
typeof p.session          // undefined
typeof p.codeVerification // undefined
typeof p.backupCode       // undefined
typeof p.utilisateur      // 'object' (jobPipeline a déjà ce modèle)

Le smoke test (smoke-test-auth-package.mjs) passe quand même, car il ne fait qu'instancier les repositories sans jamais appeler une vraie méthode Prisma (prisma.session.findFirst() etc.) — il ne prouve donc PAS que le module fonctionnerait avec de vraies requêtes. Dès qu'un use case exécuterait une opération réelle (connexion, création de session...), ça plante avec TypeError: Cannot read properties of undefined.

C'était déjà noté comme « non résolu » dans le rapport du 2026-07-02, mais c'est maintenant concrètement démontré, et c'est le même mécanisme que la découverte react-router-dom : avec file:, chaque package utilisait sa propre instance isolée de @prisma/client (générée depuis son propre schéma) — ce qui masquait ce problème exactement comme file: masquait le doublon de contexte Router. Avec un vrai dédup, les deux problèmes redeviennent visibles.

Statut définitif¶

Aspect	file: (2026-07-02)	tarball (2026-07-03)
react-router-dom dédupliqué	❌ Non (croyance erronée)	✅ Oui, vérifié
zustand dédupliqué	❌ Non	✅ Oui, vérifié
Conflits peer deps visibles	Masqués	Révélés (@hookform/resolvers, lucide-react)
@prisma/client partagé	Non (isolé par package)	Oui — révèle le besoin de merger le schéma
Backend "prêt à l'usage réel"	Apparence trompeuse	Non : merge schéma Prisma requis avant toute vraie requête
Frontend "prêt à l'usage réel"	Apparence trompeuse	Router OK ; @hookform/resolvers et lucide-react à aligner

Prochaines étapes avant une intégration réelle dans jobPipeline¶

Fusionner auth-backend/prisma/auth.prisma.fragment dans jobPipeline/BackEnd/prisma/schema.prisma (collision avec le modèle Utilisateur existant à résoudre).
Aligner @hookform/resolvers et lucide-react entre jobPipeline et le package (ou élargir les peerDependencies du package après vérification de compatibilité, comme fait pour zustand).
Toujours valider via tarball (npm pack), jamais via file: sur un dossier, pour tout test d'intégration futur.