You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 8, 2026. It is now read-only.
name: ✨ Nouvelle fonctionnalitéabout: Proposer une nouvelle fonctionnalité ou une amélioration.title: '[FEATURE] : Refactor container Inversify → Express natif'labels: enhancementassignees: @docteur-turboss
Contexte et problème actuel
Le projet utilise actuellement InversifyJS comme conteneur d'injection de dépendances. Bien que robuste, cette approche présente aujourd’hui plusieurs freins :
Courbe d’apprentissage raide pour les nouveaux développeurs rejoignant l’équipe (notamment ceux moins familiers avec les concepts avancés de l’IoC).
Complexité accrue pour des besoins d’architecture parfois simples.
Surcharge en runtime liée à la réflexion et à l’utilisation des décorateurs TypeScript.
Overhead non négligeable sur les performances globales, surtout pour des middlewares et endpoints à haut volume de trafic.
Proposition
Refactorer l’initialisation de l’application pour supprimer Inversify et revenir à un modèle plus simple, explicite et basé sur Express natif, tout en conservant la séparation des responsabilités (routes, services, middlewares, etc).
Ce refactor inclut :
Suppression des décorateurs et du conteneur @injectable, @inject, etc.
Création explicite des services via des usines ou initialisation manuelle.
Enregistrement direct des middlewares et routes dans Express sans passer par des bindings dynamiques.
Refactor des tests unitaires pour se baser sur des mocks simples plutôt que sur des bindings Inversify.
Bénéfices attendus
Développeurs plus autonomes rapidement sur le codebase (onboarding accéléré).
Lisibilité accrue du flux d'exécution et des dépendances.
Performances améliorées (moins de réflexion, moins d’abstractions runtime).
Réduction du temps de debug (stacktraces plus simples, moins de "magie").
Critères d'acceptation (DoD)
L'application fonctionne sans Inversify
Tous les services critiques sont instanciés manuellement ou via usines
Les tests unitaires ont été mis à jour (remplacement des mocks Inversify)
Le changelog documente le changement d’architecture
Une note de migration est disponible pour les développeurs
Priorité / Complexité estimée
Priorité: P1 (impact important sur la DX et la maintenabilité)
Complexité: Moyenne (répétitif mais peu risqué si bien isolé)
Contexte et problème actuel
Le projet utilise actuellement InversifyJS comme conteneur d'injection de dépendances. Bien que robuste, cette approche présente aujourd’hui plusieurs freins :
Proposition
Refactorer l’initialisation de l’application pour supprimer Inversify et revenir à un modèle plus simple, explicite et basé sur Express natif, tout en conservant la séparation des responsabilités (routes, services, middlewares, etc).
Ce refactor inclut :
@injectable,@inject, etc.Bénéfices attendus
Critères d'acceptation (DoD)
Priorité / Complexité estimée