Corriger les Assets Laravel Vite qui Chargent depuis le Serveur de Développement en Production – Guide Complet

Déployer une application Laravel avec Vite peut parfois générer des problèmes inattendus. L'un des maux de tête les plus courants est quand votre site de production essaie de charger les assets depuis localhost:5173, au lieu des fichiers compilés de /public/build.

Si votre site ne fonctionne pas en production à cause de cela, ne vous inquiétez pas — ce guide fournit une correction réelle testée sur plusieurs déploiements. À la fin, vous ne résoudrez pas seulement le problème, mais vous mettrez aussi en place un workflow fiable qui garantit que cela ne se reproduira plus.

Comprendre le Problème

En travaillant localement, Laravel avec Vite utilise un serveur de remplacement de modules à chaud (HMR) tournant sur http://localhost:5173. Cela rend le développement rapide et efficace, avec des mises à jour instantanées du navigateur.

Mais voici le problème :

• En production, votre serveur n'exécute pas ce serveur de développement.
• À la place, il devrait servir les assets pré-compilés dans /public/build.
• Si vous voyez des références comme celle-ci en production :

<link rel="stylesheet" href="http://localhost:5173/resources/css/app.css">

au lieu de :

<link rel="stylesheet" href="https://yourdomain.com/build/assets/app-xxxx.css">

…cela signifie que Laravel essaie toujours d'utiliser le serveur de développement hot reload.

Le coupable ? Un fichier public/hot résiduel qui dit à Laravel de continuer à utiliser localhost:5173.

Correction Rapide pour la Production

Exécutez ces commandes sur votre serveur de production :

cd /home/username/public_html
rm -f public/hot
php artisan config:clear
php artisan cache:clear
php artisan view:clear

✅ Cela supprime le fichier hot et vide les caches Laravel. ✅ Rechargez ensuite votre site — il devrait immédiatement utiliser les assets compilés.

Correction Permanente avec Workflow de Déploiement

Réparer manuellement convient pour une fois. Mais si vous déployez souvent, vous voulez de l'automatisation.

Étape 1 – Mettre à jour .gitignore

Assurez-vous que public/build n'est pas ignoré, car vous avez besoin des assets compilés en production :

# Garder le dossier build dans le repo
!public/build

Étape 2 – Toujours Compiler Localement

Comme votre serveur de production n'a pas npm, compilez les assets avant de pousser :

npm run build
git add .
git commit -m "Build assets for production"
git push origin main

Étape 3 – GitHub Actions pour le Déploiement

Mettez à jour votre workflow GitHub Actions pour :

• Déployer le code
• Supprimer public/hot
• Vider les caches

Exemple d'extrait de workflow :

- name: Remove hot file
  run: rm -f public/hot

- name: Clear Laravel caches
  run: |
    php artisan config:clear
    php artisan cache:clear
    php artisan view:clear

Bonnes Pratiques – À Faire et à Ne Pas Faire

✅ À faire :

• Exécuter npm run build avant de déployer
• Commiter /public/build dans votre dépôt
• Automatiser le vidage du cache

❌ À ne pas faire :

• Exécuter npm run dev en production
• Commiter public/hot
• Oublier de compiler avant de pousser

Workflow de Déploiement Typique

Voici à quoi devrait ressembler votre cycle développement → production :

# Développement local
npm run dev  

# Avant le déploiement
npm run build  
git add .  
git commit -m "Production build"  
git push origin main  

Votre pipeline CI/CD (GitHub Actions, Forge, etc.) s'occupe du reste.

Résultats pour les Clients

En corrigeant ce problème, les clients obtiennent :

• Un site de production entièrement fonctionnel sans CSS/JS cassés.
• La confiance que les déploiements ne se casseront plus.
• Un workflow optimisé pour les projets Laravel + Vite.
• Moins de temps d'arrêt, ce qui impacte directement l'expérience utilisateur et les conversions.

Cela construit la confiance dans votre expertise et fidélise les clients.

Questions Fréquentes

Q1 : Pourquoi Laravel charge-t-il les assets depuis localhost:5173 en production ? Parce que le fichier public/hot existe encore, faisant croire à Laravel qu'il doit utiliser le serveur de développement.

Q2 : Puis-je corriger cela sans GitHub Actions ? Oui. Supprimez manuellement public/hot et recompilez les assets localement avant de déployer.

Q3 : Dois-je commiter /public/build ? Oui, car votre serveur de production peut ne pas avoir Node/NPM.

Q4 : Et si j'utilise Laravel Forge ou Vapor ? Le même processus s'applique — compilez toujours les assets localement et commitez /public/build.

Q5 : Dois-je jamais exécuter npm run dev en production ? Non, c'est uniquement pour le développement local. Utilisez npm run build pour la production.

Q6 : Comment savoir si c'est corrigé ? Vérifiez le code source HTML de production. Si les URLs d'assets chargent depuis /build/assets/… au lieu de localhost:5173, c'est bon !

Conclusion

Corriger les assets Laravel Vite qui chargent depuis le serveur de développement en production est simple une fois que vous connaissez la cause — le fichier public/hot. Avec la correction rapide et un workflow de déploiement robuste, vous garantirez que les déploiements en production chargent toujours les bons assets compilés.

Cela ne résout pas seulement le problème immédiat, mais vous donne aussi un processus pérenne qui construit la confiance des clients et maintient les environnements de production stables.