13.x van Laravel 13 gebruikt en voor de implementatie van het framework de nieuwste release v13.34.0.
loadRoutesFrom laadt alleen een bestand
ServiceProvider::loadRoutesFrom() laadt het routebestand niet als de applicatie CachesRoutes implementeert en routesAreCached() true teruggeeft. In alle andere gevallen wordt het opgegeven bestand met require geladen.
De methode zelf voegt geen URI- of routenaamprefix, controller-namespace of middleware toe. Ze publiceert ook geen bestanden en voegt geen routes toe aan een bestaande cache.
Het diagram gaat uit van een standaard Laravel-applicatie. Er bestaat geen aparte cache voor het package: de routes van het package maken deel uit van de routecache van de hele applicatie.
Configuratie en registratie scheiden
In het volgende voorbeeld maak je een openbaar endpoint dat aangeeft of het package beschikbaar is. We gaan ervan uit datAcme\Courier\ via PSR-4 in Composer aan src/ is gekoppeld en dat de provider via automatische detectie of handmatig is geregistreerd.
config/courier.php
register() en laad de routes in boot(). Maak een provider die HTTP-routes registreert geen DeferrableProvider, want dan is niet meer gegarandeerd dat de provider is opgestart op het moment dat de routes nodig zijn.
src/CourierServiceProvider.php
routes/web.php
src/Http/Controllers/StatusController.php
/acme-courier/status en de routenaam is acme-courier.status. Als je URL’s genereert met route('acme-courier.status'), kan de aanroepende code dezelfde routenaam blijven gebruiken, ook als de URI-prefix verandert. name() op een groep plakt de strings letterlijk aan elkaar, dus geef ook de afsluitende . op.
web vervangt geen authenticatie of autorisatie. Dit voorbeeld is een openbaar endpoint zonder gevoelige gegevens. Voor endpoints die gegevens van gebruikers teruggeven, voeg je afzonderlijk authenticatiemiddleware en autorisatie toe die bij de specificatie passen.Botsingen van URI’s en routenamen afzonderlijk voorkomen
De URI-prefix en de routenaamprefix zijn afzonderlijke mechanismen. Als je er maar één toevoegt, voorkom je geen botsingen bij de andere.
Wanneer
AbstractRouteCollection een routecollectie voor de cache opbouwt, gooit het een LogicException als een andere route dezelfde naam heeft. Dat je bij een normale start URL’s kon genereren, garandeert dus niet dat de routes te cachen zijn. Ook twee routes met verschillende URI’s veroorzaken een probleem als ze dezelfde naam hebben.
Maak het overschrijven van routes van de applicatie via de registratievolgorde geen manier om het package uit te breiden. Bied indien nodig een instelling om de routes uit te schakelen en een service die gebruikers vanuit een eigen route kunnen aanroepen.
De configuratie bij het aanmaken van de cache blijft in de routedefinities
RouteCacheCommand voert eerst route:clear uit, start daarna een nieuwe applicatie op en verzamelt de routes. Vervolgens worden die routes serialiseerbaar gemaakt en wordt het gecompileerde resultaat naar het cachebestand geschreven.
Omdat daarbij ook het routebestand van het package wordt geladen, worden de prefix en het wel of niet registreren bepaald door de configuratie op het moment dat de cache wordt aangemaakt. Bij latere starts laadt loadRoutesFrom() het bestand niet en worden de gecachte routes gebruikt.
Registreer routes niet op basis van voorwaarden die per request verschillen, zoals de gebruiker of tenant. Zulke voorwaarden worden geëvalueerd in de CLI-omgeving waarin de cache wordt aangemaakt. Registreer routes met een stabiele configuratie en beslis over toegang met middleware of autorisatie in de controller.
Leg bij een deployment eerst de configuratie vast
Werk eerst de code en de configuratie bij. Gebruikt je setup de configuratiecache, maak de caches dan in de volgende volgorde opnieuw aan. Neem dit op in het deploymentproces van de applicatie.route:cache uitvoert terwijl er nog een oude configuratiecache is, worden ook de routes met de oude configuratie aangemaakt. Alleen config:cache opnieuw uitvoeren werkt de routecache niet bij. Met -vv kun je ook de inhoud van middlewaregroepen controleren.
Wil je tijdens de ontwikkeling het gedrag zonder cache controleren, wis dan zo nodig beide.
Combinaties die je vóór een release controleert
Controleer naast de tests van het package de volgende combinaties in een Laravel 13-applicatie die het package gebruikt. Test niet alleen de registratie van routes in het geheugen, maar ook het pad waarin Artisan een nieuwe applicatie opstart.- Zonder cache reageert
/acme-courier/statusen zijn de routenaam en middleware zoals verwacht. route:cacheslaagt en ook bij een nieuwe start reageert het endpoint met dezelfde URI en routenaam.- Na het wijzigen van de prefix en het opnieuw aanmaken van de cache reageert de nieuwe URI en is de packageroute onder de oude URI verdwenen.
- Na uitschakelen en het opnieuw aanmaken van de cache verschijnt de route niet in
route:list --name=acme-courier. - URI’s en routenamen botsen niet met die van de applicatie of andere packages.
Gerelateerde pagina’s
Routing
Bekijk de basis van routegroepen, benoemde routes en het weergeven van routelijsten.
Packageconfiguratie samenvoegen en cachen
Bekijk updateprocedures die rekening houden met gepubliceerde configuratie en de configuratiecache.
Uitgestelde service providers
Bekijk waarom je providers die routes registreren niet uitstelt.
Versiecompatibiliteit van packages beheren
Koppel wijzigingen in de publieke API aan je releasebeleid en doorlopende controles.
Geraadpleegde primaire bronnen
- Officiële Laravel-documentatie: routes van packages
- Officiële Laravel-documentatie: routing
- ServiceProvider: implementatie van loadRoutesFrom
- RouteServiceProvider: laden van de cache
- RouteCacheCommand: verzamelen en opslaan in een nieuwe applicatie
- AbstractRouteCollection: detectie van dubbele routenamen