- Ajout de --include=dev pour installer tsx nécessaire à build:data
- Le script build:data utilise tsx qui est dans devDependencies
- Cela devrait résoudre l'erreur exit code 127 pour build:data
- Utilisation de WORKDIR pour changer de répertoire de manière fiable
- Cela évite les problèmes avec cd qui peuvent échouer silencieusement
- WORKDIR garantit que npm est disponible dans le bon contexte
- Retour à /app après le build
- Vérification que npm est disponible
- Vérification du répertoire de travail
- Séparation des commandes build:data et build pour identifier quelle étape échoue
- Cela devrait aider à identifier pourquoi exit code 127
- Copie de radar, public, config.json, about.md, custom.css dans .techradar
- Exécution de build:data avant build pour générer les données
- Cela reproduit ce que fait techradar.js automatiquement
- Le build devrait maintenant fonctionner correctement
- Ajout de vérifications pour voir si npm est disponible
- Affichage du package.json en cas d'échec pour déboguer
- Cela devrait aider à identifier pourquoi npm run build échoue
- Séparation de la commande de création du hash en une commande RUN distincte
- Utilisation de fs.writeFileSync au lieu de echo pour éviter les problèmes d'échappement
- Cela devrait résoudre l'erreur exit code 2
- Le script techradar.js ne prend pas 'install' comme paramètre
- Création manuelle de .techradar en copiant depuis node_modules/aoe_technology_radar
- Création du fichier hash pour éviter la recréation à chaque fois
- Cela évite les problèmes avec la commande 'install' qui n'existe pas
- Utilisation de 'node node_modules/aoe_technology_radar/bin/techradar.js install'
- Ajout d'une vérification pour voir si le binaire existe
- Cela évite les problèmes avec les permissions ou le chemin du binaire
- Remplacement de 'npx techradar install' par './node_modules/.bin/techradar install'
- Cela évite les problèmes avec npx qui peut ne pas trouver le binaire
- Le binaire est disponible après l'installation de aoe_technology_radar
- Séparation de la commande RUN complexe en plusieurs RUN distincts
- Cela permet d'identifier plus facilement quelle étape échoue
- Suppression du patch next.config.js qui n'est plus nécessaire en mode production
- Changement de NODE_ENV de development à production dans Dockerfile.business
- Build de l'application en mode production dans le Dockerfile
- Modification de start-business.sh pour utiliser 'next start' au lieu de 'next dev'
- Cela désactive complètement Fast Refresh et évite les rechargements en boucle
- Le mode production n'utilise pas Fast Refresh, donc pas de problème avec webpack hot-update
- Ajout d'un patch dans Dockerfile.business pour modifier next.config.js après installation
- Le patch supprime ReactRefreshPlugin de la configuration webpack en mode développement
- Cela devrait empêcher Fast Refresh de déclencher des rechargements en boucle
- Le problème venait du fait que le script strategie-script.js modifie le DOM, ce qui déclenche Fast Refresh
- Correction du Dockerfile.business pour préserver la structure radar/2025-01-15/ au lieu de copier directement dans radar/
- Cela permet au framework de parser correctement les dates et d'afficher les releases
- Ajout du script scripts/verify-blips.js pour vérifier le format des blips et des dates
- Tous les 36 fichiers blips vérifiés et validés (title, ring, quadrant, tags présents)
