Routing Laravel Package

Product Decisions This Supports

Owning the URL namespace as a product surface. The package's core idea is a single registry where every public address is one row with one owner and one resolver. That reframes "who controls /acme?" from an accident of route-file ordering into a data-integrity rule. It is a decision worth making deliberately — nearly free before the second team ships a conflicting slug, a migration plus an SEO incident after.

Editor-owned URLs vs. developer-owned routes. A registry keyed by owner lets marketing rename a campaign page without a deploy. That is the difference between a URL change being a backlog ticket and a five-minute admin action, and it unblocks roadmap items — per-market localized slugs, self-serve SEO metadata, campaign landing pages, vanity paths — that would otherwise each become their own engineering project.

Redirects as a platform guarantee, not individual diligence. If the registry owns the mapping, a slug change emits a 301 systematically. Preserved link equity and a contained 404 rate become properties of the platform rather than of whoever wrote the last controller. That is a defensible SEO commitment you can put in a roadmap and hold the team to.

Build vs. buy vs. fork — framed honestly. With zero stars, zero dependents, and no production signal, the real decision is not "adopt this package," it is "adopt this pattern." The credible options are: (a) native Laravel routing plus spatie/laravel-sluggable, (b) a CMS or commerce platform that already ships URL management, or (c) a thin in-house registry — one table, one resolver contract, one admin screen, one backfill command. At most companies' scale, (c) is the strongest candidate and this repo is the reference design for it.

Decoupling content from persistence. Because the resolver delegates rather than assuming Eloquent, new entity types can be added by other teams or plugins without touching core route files — and the door stays open to moving content behind a headless service later without re-platforming the URL layer.

Multi-site and locale scoping — decide now, not later. A path-keyed registry naturally grows site/locale/channel dimensions. Choosing whether the namespace is global or per-site is nearly free today; backfilling it after launch is a schema migration plus an SEO incident.

What I would explicitly not use it for. The Blade menu/link/active-state helpers the description leads with. That is a ternary and a request()->is() call — a half-day of in-house work. Pulling an unmaintained dependency to avoid writing it adds a second, unrelated failure surface to a package you are already pinning.

Metrics to hold the team to: percentage of live URLs registered, 404 rate on legacy paths, redirect coverage after slug changes, duplicate-slug incidents per release, time-to-publish a URL change, and p95 path-lookup latency. That last one matters because this design puts a lookup on the hot path for every request that misses a static route — caching is a product requirement, not a later optimization.

When to Consider This Package

Consider it when:

• You have three or more entity types sharing one public namespace and genuinely need one authority arbitrating who owns a given path.
• Non-engineers rename URLs, and you need uniqueness enforcement plus redirect history rather than trusting people to remember.
• You are migrating a legacy site — the strongest concrete use case: a table you can backfill and crawl-diff before cutover, with the old site as the source of truth until it isn't.
• You want routing decoupled from persistence, so an owner can be an Eloquent model, an API resource, or a stub mid-migration.
• You are prepared to pin the source and own it. Treat adoption as forking the design — that is effectively what you are doing.

Look elsewhere when:

• You have a handful of static or resourceful routes. Laravel's router, route model binding, and route caching already solve this with zero added dependency, zero extra query, and zero new failure mode.
• You need proven, maintained dependencies. Zero stars, zero dependents, score of 0 — no third party has validated this in production, there are no downstream users to inherit bug reports from, and there is no signal on release cadence, test coverage, or backward-compatibility posture. MIT removes legal friction but confers no support.
• Hot-path performance is tight and you cannot cache. A table read per request is fine with a warmed cache and a poor fit without one.
• No one owns the backfill and the 404 monitor. Without those, a missing registry row silently converts an indexed URL into a 404 with nothing to alert on. That is the real risk here, and it is an operational commitment, not a code one.

The adoption gate I would set: a two-day spike on one entity type (a Product with an editor-assigned slug), proving four things end-to-end — register a path, resolve it, rename it and confirm the old path 301s, and deliberately collide two paths to see whether you get an exception, an overwrite, or silence. That collision test is the one that tells you whether this is a routing layer or a liability. Fund the spike before the roadmap conversation.

How to Pitch It (Stakeholders)

To executives: we have an opportunity to make URLs a product surface instead of an engineering artifact — marketing renames pages without a deploy, redirects happen automatically, and we stop losing search traffic to stale links. The idea is sound; the specific library is unproven, so the recommendation is to adopt the pattern with a small in-house implementation that we own outright, using this repo as the reference design. Cost is roughly a two-day validation spike plus a sprint of build, versus a per-request ticket drain forever. Success is measured by 404 rate on legacy paths, redirect coverage after renames, and time-to-publish a URL change.

To engineering: this is not a dependency recommendation. Zero stars, zero dependents, no release cadence, no test signal — we would be consuming an unmaintained reference implementation, so we pin it or, better, vendor the concept. What is worth taking is the architecture: one table keyed on a normalized path with a unique index, one row per addressable entity, a resolver contract that delegates via a morph map so a new entity type is a new resolver plus a registration line rather than an edit to routes/web.php. Integration is a single fallback route plus one middleware placed after tenancy and locale resolution — everything else stays native Laravel. Non-negotiables if we proceed: explicit collision semantics (throw, don't silently overwrite), normalization enforced in the schema and not the resolver, cache invalidation in the same transaction as the write, redirects as first-class writes on rename, a 404 log as the backfill backlog, and an inspection command (registry:show {path}) on day one. Wrap the resolver contract behind our own interface so that replacing the package with twenty lines of Eloquent is a file swap, not a refactor. Assume we own this within a year and structure the code accordingly.