Laravel Routes Core Laravel Package

Product Decisions This Supports

• Still a dependency decision, not a feature enabler. laravel-routes-core remains the shared core of the Dragon Code routing stack, intended to arrive transitively via dragon-code/laravel-routes rather than be adopted directly. The product decision it informs is build vs. buy for route-definition conventions (auto-registration, grouping, route metadata/listing helpers) — not a roadmap item.
• Release 5.4.0 is housekeeping plus one compatibility patch. The only substantive commit is Laravel 13 support (#43); the remainder is a logo replacement, an automated LICENSE year bump, and banner/preview image updates. There is no new capability, no API surface change, and nothing that alters the ceiling on user value. Route declaration remains a thin, well-served Laravel surface.
• The maintenance signal improved; the adoption signal did not. A maintainer-authored framework-compatibility commit is meaningful evidence that the package is being kept alive for major Laravel versions — that directly retires the earlier "no PHP/Laravel major-version guarantees" concern. It does not retire the low-adoption concern (still no meaningful dependent base or issue-resolution history to inspect), so the TCO case for direct adoption stays weak.
• Diligence note on release cadence. This release pattern — bot-driven housekeeping releases interleaved with occasional single-commit compat patches — is what a maintained-but-unused package looks like. Treat it as health evidence for pinning, not as traction evidence for adopting. Release recency should still not be read as product signal.
• Verdict: no action on our roadmap. If the package appears in our tree via dragon-code/laravel-routes, 5.4.0 is a good pin target (Laravel 13 ready). As a direct dependency for our own code, the answer is unchanged: not a candidate for a spike.

When to Consider This Package

Consider it when:

• You have already committed to dragon-code/laravel-routes and this arrives transitively — pin to 5.4.0 or later, audit, and monitor. With Laravel 13 compatibility landed, pinning is now materially safer than it was at the prior review.
• You are standardizing on the Dragon Code ecosystem (laravel-data, laravel-actions, etc.) and value authoring-consistency over dependency minimalism.
• You need a reference implementation — MIT-licensed, small, readable — for structured route registration. Copying patterns remains legitimate; depending on it for our own routing does not.
• You are on, or planning, Laravel 13 and the package is already in your tree: this release is the version to hold.

Look elsewhere when (i.e., almost always for direct use):

• You need standard route registration: Laravel's Route:: facades and Laravel 11+ attribute routing.
• You need controller auto-discovery: spatie/laravel-route-attributes.
• You need to expose routes to the frontend: tightenco/ziggy.
• You need page-based routing without controllers: laravel/folio.
• Remaining disqualifiers for direct production adoption: effectively zero adoption (no community canary for breakage), thin issue-resolution history, and single-maintainer bus factor. The prior "archived / unpatchable" objection is now softened by 5.4.0, so this drops from disqualifying to strongly discouraging — but the adoption and bus-factor concerns alone still keep it out of our own dependency manifest.

If a stakeholder insists: timebox a one-day spike, vendor the code under our namespace with tests, and adopt the MIT terms rather than the package. The Laravel 13 patch is small enough to carry forward ourselves if needed.

How to Pitch It (Stakeholders)

Executive summary: This is a small internal component library from a third-party ecosystem, not a product capability. The new 5.4.0 release is maintenance, not functionality: it adds Laravel 13 compatibility and updates branding/licensing files. It shows the author is keeping the package alive for current framework versions, which is reassuring where it appears in a dependency tree, but it does not change the fundamentals — minimal adoption, single maintainer, and a surface Laravel already provides natively. Recommendation: do not adopt directly; no roadmap impact. If it arrives transitively, pin 5.4.0.

For engineering: The upgrade is safe and additive — one compat commit plus housekeeping, no breaking changes or deprecations. If laravel-routes-core is in our tree via dragon-code/laravel-routes, move the pin to 5.4.0 and keep it on the dependency-watch list. For anything we would build ourselves, use core Laravel routing plus a maintained package (spatie/laravel-route-attributes, ziggy, folio) as appropriate; if a specific behavior proves genuinely useful, spike it and vendor the MIT-licensed code under our namespace with tests rather than taking on the dependency. Revisit only if upstream shows real adoption growth.