Has Parameters Laravel Package

Product Decisions This Supports

• Ship route-scoped variations without changing the URL surface. Attach context to a route definition — experiment cohort, pricing segment, plan tier, locale hint, onboarding step — and read it through Laravel's standard route parameter bag. Product can vary behavior across routes without touching paths, query strings, or client-facing link contracts.
• Protects SEO, sharing, and analytics continuity. Because the metadata never appears in the URL, canonical URLs, deep links, campaign tracking, and mobile clients that hardcode paths stay stable. This is the core product benefit: experimentation without link churn.
• Build vs. buy. Replaces the informal workaround most teams converge on — ->defaults() sprinkled ad hoc, or associative arrays hardcoded in middleware and controllers — with one expressive, documented convention. Low build cost either way; the package mainly buys consistency.
• Use cases worth naming in a roadmap review: per-route feature gating, per-route rate-limit or entitlement tiers, authorization hints (which policy/guard applies), A/B assignment at the route level, redirect targets for legacy paths, and internal-only route labeling for admin surfaces.
• De-risks "make it configurable" asks that are really routing asks. A recurring class of request ("show the new checkout only for enterprise accounts", "route EU traffic to the localized flow") becomes a route-definition change rather than a new config file, middleware branch, or URL scheme.
• Cadence signal for planning. v1.5.3 is a dependency bump adding Laravel 13 support — no feature work. Read this as feature-complete and maintenance-only: safe as infrastructure, not a bet on future capability. Don't schedule roadmap items that assume it grows into a runtime configuration platform.
• Sets an honest boundary for the roadmap. This package is deploy-time metadata. If a PM requirement is "marketing flips a flag on Tuesday without a release," that is a different product decision and a different vendor.

When to Consider This Package

Adopt when:

• You need contextual data attached to a route that should not be visible to end users in the URL or query string.
• The values are stable at deploy time and legitimately belong in code — experiment labels, segment hints, policy hints, admin-only route tags.
• You want the value available in middleware, controllers, route model binding, or form requests with no database hit and no new service.
• You need it to survive php artisan route:cache and to compose with route groups — both are explicit design goals of the package.
• You're planning a Laravel upgrade; v1.5.3 widens constraints for Laravel 13, so forward compatibility is handled.

Look elsewhere when:

• The value must change at runtime without a deploy. Route parameters are compiled into the route cache. Flipping one means shipping code. Use a feature-flag service (LaunchDarkly, ConfigCat, Unleash) or database-backed config instead.
• The value is per-user or per-tenant. Those aren't route-scoped; they belong in user/tenant settings or a configuration store.
• You need an audit trail, approval workflow, or non-engineer editing. None of that exists here, and none of it is coming — the release cadence says so.
• You need to query, sort, or aggregate on the values. They are runtime route metadata, not queryable data.
• You're storing something sensitive. Route parameters are not secret storage: they live in application code, may be present in cached route files, and can surface in debug output or error pages that dump route data.
• The need is two or three static values. Laravel's built-in ->defaults('key', $value) is the plainest tool and adds no dependency.

How to Pitch It (Stakeholders)

Executives. A small, MIT-licensed library that lets engineering attach business context — experiment cohorts, plan tiers, regional hints, feature gates — to application routes without changing any URLs. The commercial win is narrow but real: we can run route-level experiments and segment rollouts without breaking links, SEO, or mobile clients that hardcode paths. Cost is effectively zero — one Composer dependency, no infrastructure, no new service to operate — and the maintainer's recent release was a compatibility bump only, so churn is minimal. The one caveat to state plainly: values are set at deploy time, so this is engineering plumbing, not a self-serve toggle panel for marketing. Bus factor is a single maintainer; the footprint is small enough to vendor if it ever becomes load-bearing.

Engineering. A trait/fluent API on the route definition; values are read back through the standard route parameter bag, so there's no new access pattern to learn and no divergence from framework idiom. Confirmed to work with route groups, model binding, and route caching — the last one matters, because it constrains what this can ever be: values are compiled into the cached route file and therefore change only on deploy. Treat it as record-of-intent for a route, not a feature-flag system. Two house rules before rollout: (1) namespace keys (checkout.experiment, billing.tier_hint) so they don't collide across teams, and (2) never put secrets or per-user data in them. Pair it with the flag service for anything marketing needs to flip live, and with the database for anything user-specific. v1.5.3 is a constraint-widen-only patch — zero API change, zero migration; fold it into the next routine dependency refresh rather than a dedicated workstream, and confirm in CI that our PHP/Laravel pair is actually covered rather than trusting the "Laravel 13" framing in the release note.