Aller au contenu

Test d'intégration des packages auth : file: vs tarball — la vraie découverte fondatrice

Contexte

Avant même le câblage réel documenté dans jobPipeline/architecture/procedure-cablage-auth-package, deux tests d'intégration successifs (2026-07-02 puis 2026-07-03) ont été menés pour valider si @kanmaber/auth-backend/auth-frontend (extraits de ProjetESM) étaient réutilisables « en état » dans jobPipeline. Ces tests sont à l'origine de la décision de distribuer le package via .tgz plutôt que file: sur un dossier — décision qui a ensuite causé le piège de cache npm documenté dans jobPipeline/debug/lecons-cablage-auth-package.

Contenu

Test 1 (2026-07-02) — via file:../../Shared/packages/... (dossier)

  • Backend : installation et typecheck OK, smoke test OK (34 use cases, 36 controllers instanciés sans DB réelle).
  • Point non résolu déjà identifié : le package utilise son propre schéma Prisma, sans collision visible car aucune requête réelle n'était faite.
  • Frontend : install et typecheck OK, mais risque découvert — npm ls révèle react-router-dom/zustand/lucide-react installés en double (version racine jobPipeline vs version imbriquée dans le package). Risque théorique de contexte Router cassé à l'exécution, non vérifiable à ce stade (pas de frontend scaffoldé).

Test 2 (2026-07-03) — via tarball (npm pack + .tgz)

Refait spécifiquement parce qu'une question annexe sur react-router-dom a révélé 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 avec file: sur un dossier).

Résultats, une fois dédupliqué correctement par tarball :

Aspect file: (02/07) tarball (03/07)
react-router-dom/zustand dédupliqués ❌ Non (croyance erronée) ✅ Oui, vérifié par require.resolve()
Conflits peer deps (@hookform/resolvers, lucide-react) Masqués Révélés immédiatement au premier npm install strict
@prisma/client partagé Non (isolé par package) Oui — révèle que jobPipeline n'a pas encore les modèles session/codeVerification/backupCode (typeof p.session === 'undefined')
Smoke test "preuve" de fonctionnement Trompeur (n'appelle aucune méthode Prisma réelle) Toujours trompeur pour la même raison, mais le problème sous-jacent est désormais visible autrement

Enseignement clé : file: sur un dossier masque à la fois les problèmes de déduplication de modules ET les conflits de peer dependencies. Un test d'intégration qui utilise file: donne une fausse impression de compatibilité. Le tarball (npm pack) est la seule méthode qui reproduit fidèlement un vrai npm install depuis un registre.

Décision / Conclusion

Toujours valider une intégration de package local via tarball (npm pack), jamais via file: sur un dossier. Cette règle a motivé le choix initial de distribution en .tgz pour @kanmaber/auth-backend (confirmé dans la procédure de câblage réelle) — un choix qui a ensuite eu sa propre contrepartie (le piège de cache npm sur les dépendances file:...tgz, documenté séparément) mais qui reste le bon compromis face au risque de désynchronisation Prisma identifié plus tard (voir jobPipeline/debug/lecons-cablage-auth-package, leçon sur le rejet de l'option dossier symlinké).

À faire (au moment de ces tests, largement traité depuis)

Liens connexes