dragon-code/extended-routes
A small Laravel package that extends the native router with extra helper methods and macros, letting you declare routes more concisely while staying fully compatible with standard Laravel routing, middleware, and route caching.
Architecture fit. The package is a thin extension over Laravel's Route facade, registering resource-style macros that emit additional routes for soft-deleted model operations (restore, force-delete) and bind resolution through withTrashed(). That is idiomatic Laravel: service-provider auto-discovery, no container gymnastics, no persistence layer, no async machinery. It lives entirely in the HTTP routing layer and does not touch domain logic or storage. Architecturally the fit is high — it fills a genuine ergonomic gap that Laravel core has never closed.
Integration feasibility. Effort is trivial: composer require, auto-discovered provider, macros available immediately. More importantly, replacing it is also trivial. The emitted routes are the same explicit routes a team would write by hand using ->withTrashed() plus a Route::bind closure or a resolveRouteBinding override — roughly 40–80 lines across a service provider and a trait. The package's value is convenience, not capability.
Technical risk. Risk is dominated by lifecycle, not by code quality. The repository is archived, last release 2024-03-15, 16 stars, 0 dependents. Archived means no compatibility work for Laravel 11/12, no security triage, no bug fixes, no PHP 8.3/8.4 test matrix. Zero dependents means effectively no field validation and no community fallback. The MIT license is the one strong mitigant: forking or vendoring is legally and practically free, which de-risks the content but not the support obligation.
Key questions.
apiResource variants), or one or two endpoints?route:cache / route:list, and would a macro-based package interact badly with either?Stack fit. Only sensible in a Laravel application where soft deletes are a first-class domain concept and restore/force-delete endpoints are exposed through resource routing. Irrelevant to API surfaces that hand-roll route definitions, and irrelevant outside Laravel.
Migration path. The recommended path is reimplementation, not adoption. (1) Inventory every route the macros generate or would generate. (2) Replace with explicit definitions using withTrashed() bindings plus a small trait or Route::bind closure. (3) Only if the macro surface proves genuinely broad, fork into a private package under our namespace, pin it, and add Laravel-version CI. Both paths remove the archived public dependency; the first removes the dependency entirely.
Compatibility. Treat the supported Laravel version as frozen at whatever it shipped against. Verify with composer why, composer outdated, and a full route:cache / route:clear round trip in staging before committing. Nested resources and apiResource() variants are the most likely breakage points.
Sequencing. (1) Confirm no transitive requirement. (2) If required transitively, vendor and pin immediately. (3) If greenfield, prototype the hand-rolled equivalent — a sub-day task — and diff its output against the package's route:list for parity. (4) Fork only if parity proves expensive. (5) Land a route-listing snapshot test to lock behavior before any further change.
Maintenance. The dominant cost. An archived project transfers the entire maintenance burden in-house on day one: Laravel majors, PHP bumps, security review, and route-cache regressions all become our tickets. For a package this small, the honest framing is that we would be adopting a dependency we must be prepared to own indefinitely, in exchange for saving roughly one engineer-day.
Support. None. No issue triage, no maintainer contact, no CVE feed. Internal support must come from the adopting team, documented in an ADR that names an owner.
Scaling. Negligible. Macros are evaluated at boot and compiled into the route collection; there is no per-request overhead beyond normal route matching and no data-plane concern. The only scaling-adjacent risk is route-count inflation if the macros are applied broadly, which marginally affects route:cache size and boot time.
Failure modes. (a) A Laravel upgrade silently changes macro registration, producing 404s on restore and force-delete endpoints — customer-visible and hard to detect; (b) route model binding resolves against the non-trashed scope, so restore routes 404 on exactly the records they exist to serve; (c) macro name collisions with other route extensions resolved non-deterministically by provider load order; (d) stale route cache after deploy. All are catchable with route-listing snapshot tests plus a smoke test that hits a restore endpoint against a soft-deleted fixture.
Ramp-up. Very low. Any Laravel developer reads the package in under an hour, and the hand-rolled replacement is within reach of a mid-level engineer. That low ramp-up is itself the argument against the dependency: the thing we would depend on is cheaper to own than to depend on.
Recommendation. Block adoption as an external dependency. Approve reimplementation, with a private fork as fallback if the macro surface turns out larger than expected. At 16 stars, zero dependents, and archived status, there is no ecosystem signal that justifies the permanent support burden.
How can I help you explore Laravel packages today?