Laravel Vite Assets Repareren die Laden vanaf de Ontwikkelserver in Productie – Complete Gids
Het deployen van een Laravel-applicatie met Vite kan soms onverwachte problemen opleveren. Een van de meest voorkomende hoofdpijndossiers is wanneer je productiesite assets probeert te laden van localhost:5173, in plaats van de gecompileerde bestanden uit /public/build.
Als je site kapotgaat in productie hierdoor, maak je geen zorgen — deze gids biedt een echte oplossing getest in meerdere deployments. Aan het einde los je niet alleen het probleem op, maar zet je ook een betrouwbare workflow op die ervoor zorgt dat het nooit meer gebeurt.
Het Probleem Begrijpen
Wanneer je lokaal werkt, gebruikt Laravel met Vite een hot module replacement (HMR) server die draait op http://localhost:5173. Dit maakt ontwikkeling snel en efficiënt, met directe browserupdates.
Maar hier zit het probleem:
- In productie draait je server deze ontwikkelserver niet.
- In plaats daarvan moet het de voorgebouwde assets uit
/public/buildserveren. - Als je in productie referenties ziet zoals:
<link rel="stylesheet" href="http://localhost:5173/resources/css/app.css">
in plaats van:
<link rel="stylesheet" href="https://yourdomain.com/build/assets/app-xxxx.css">
…betekent dit dat Laravel nog steeds probeert de hot reload ontwikkelserver te gebruiken.
De boosdoener?
Een achtergebleven public/hot bestand dat Laravel vertelt om localhost:5173 te blijven gebruiken.
Snelle Oplossing voor Productie
Voer deze commando's uit op je productieserver:
cd /home/username/public_html
rm -f public/hot
php artisan config:clear
php artisan cache:clear
php artisan view:clear
✅ Dit verwijdert het hot bestand en wist Laravel caches.
✅ Herlaad daarna je site — deze zou direct de gecompileerde assets moeten gebruiken.
Permanente Oplossing met Deployment Workflow
Handmatig repareren is prima voor één keer. Maar als je vaak deployt, wil je automatisering.
Stap 1 – .gitignore Bijwerken
Zorg ervoor dat public/build niet genegeerd wordt, aangezien je gecompileerde assets nodig hebt in productie:
# Bewaar build map in repo
!public/build
Stap 2 – Altijd Lokaal Bouwen
Aangezien je productieserver geen npm heeft, bouw assets voor het pushen:
npm run build
git add .
git commit -m "Build assets for production"
git push origin main
Stap 3 – GitHub Actions voor Deployment
Werk je GitHub Actions workflow bij om:
- Code te deployen
public/hotte verwijderen- Caches te wissen
Voorbeeld workflow fragment:
- 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
Best Practices – Do's & Don'ts
✅ Doe:
- Voer
npm run builduit voor het deployen - Commit
/public/buildin je repo - Automatiseer cache clearing
❌ Doe niet:
npm run devdraaien op productiepublic/hotcommitten- Vergeten te bouwen voor het pushen
Typische Deployment Workflow
Zo zou je ontwikkeling → productie cyclus eruit moeten zien:
# Lokale ontwikkeling
npm run dev
# Voor deploy
npm run build
git add .
git commit -m "Production build"
git push origin main
Je CI/CD pipeline (GitHub Actions, Forge, etc.) doet de rest.
Resultaten voor Klanten
Door dit probleem op te lossen, krijgen klanten:
- Een volledig werkende productiesite zonder kapotte CSS/JS.
- Vertrouwen dat deployments niet meer kapotgaan.
- Geoptimaliseerde workflow voor Laravel + Vite projecten.
- Minder downtime, wat direct invloed heeft op gebruikerservaring en conversies.
Dit bouwt vertrouwen in je expertise en zorgt voor terugkerende klanten.
Veelgestelde Vragen
V1: Waarom laadt Laravel assets van localhost:5173 in productie?
Omdat het public/hot bestand nog bestaat, waardoor Laravel denkt dat het de ontwikkelserver moet gebruiken.
V2: Kan ik dit repareren zonder GitHub Actions?
Ja. Verwijder handmatig public/hot en herbouw assets lokaal voor het deployen.
V3: Moet ik /public/build committen?
Ja, aangezien je productieserver mogelijk geen Node/NPM heeft.
V4: Wat als ik Laravel Forge of Vapor gebruik?
Hetzelfde proces is van toepassing — bouw altijd assets lokaal en commit /public/build.
V5: Moet ik ooit npm run dev draaien in productie?
Nee, het is alleen voor lokale ontwikkeling. Gebruik npm run build voor productie.
V6: Hoe weet ik of het gerepareerd is?
Controleer je productie HTML-bron. Als asset-URL's laden van /build/assets/… in plaats van localhost:5173, ben je klaar!
Conclusie
Het repareren van Laravel Vite assets die laden vanaf de ontwikkelserver in productie is eenvoudig zodra je de oorzaak kent — het public/hot bestand. Met de snelle oplossing en een robuuste deployment workflow zorg je ervoor dat productiedeployments altijd de juiste gecompileerde assets laden.
Dit lost niet alleen het directe probleem op, maar geeft je ook een toekomstbestendig proces dat klantvertrouwen opbouwt en productieomgevingen stabiel houdt.
