- What problem does timacdonald/has-parameters solve?
- It is a small Laravel trait that lets you attach named key-value parameters to route definitions so middleware and controllers can read contextual values without encoding them into the URL. Instead of parsing colon-delimited middleware strings, you declare parameters next to the route and read them from Laravel's standard route parameter bag. The package itself does no storage or evaluation — it is plumbing for definition-time context such as a cohort flag, locale hint, or auth hint.
- How do I install timacdonald/has-parameters?
- Run composer require timacdonald/has-parameters and apply the provided trait wherever the parameters are consumed. There is no service provider configuration, publish step, or infrastructure work required. For a Laravel team a spike on a single low-risk route group is typically an afternoon of work.
- How do I pass parameters to a middleware or route?
- You declare the parameters on the route or route group definition and read them inside the middleware through the trait rather than parsing a colon-delimited argument string. Because values are declared on the definition, route groups can share the same parameters and inherit them cleanly. In feature tests you can assert behaviour by resolving the route and inspecting its parameter bag.
- Does the package require extra database tables or migrations?
- No. Parameters live in the route definition rather than in the database, so there is nothing to migrate, no schema to design, and no extra query per request. That also means there is nothing to back up or audit automatically. If a value needs to be queried, reported on, or edited by non-engineers, this is the wrong layer.
- Is it compatible with Laravel's route caching in production?
- Yes. Because the parameters are part of the route definition, they are compiled into the cached routes, so route:cache works as usual. Confirm your deploy topology caches routes in production and clears them in CI, and re-run the cache after changing any parameter values. This is worth verifying against your pinned version before you rely on it.
- How is this different from config values or a feature flag package?
- Config is application-wide and environment-scoped, whereas these parameters are route-scoped read-time context, letting one route group behave differently without adding an environment variable. It is not a feature-flag platform: there is no evaluation SDK, targeting rules, caching layer, or admin UI. Frame it as plumbing that product logic reads from and keep anything that must be toggled by non-engineers elsewhere.
- Do these parameters show up in URLs, logs, or cache keys?
- They live outside the URL, so they do not appear in request paths, access logs, analytics, or cache keys by default. That keeps URLs clean but makes questions like 'why did this route behave differently?' harder to answer. Document the keys and consider logging them explicitly at the point where behaviour branches.
- What naming convention should we use for parameter keys?
- Use namespaced, dot-separated keys such as billing.flow or exp.checkout_v2, and keep a short registry of known keys with their documented value types. This convention substitutes for the schema and governance the package deliberately does not provide. Re-review the registry before a second consumer of the same key lands.
- Which Laravel versions are supported, and how safe are upgrades?
- v1.5.3 is a constraint-widening release that adds Laravel 13 support and remains backward compatible with v1.5.2, so there is no API change to migrate. Pin ^1.5 and confirm the constraint resolves on your target Laravel branch. On upgrade, check the composer.lock diff — if other packages move, review those rather than this one.
- Is the package actively maintained, and what are the alternatives?
- It is a single-maintainer package with roughly 229 GitHub stars and a compatibility-only release pattern, so treat it as feature-complete and in maintenance mode. Pin the version, name an accountable owner, and decide up front whether you would fork or vendor it if the maintainer goes dormant. If you need evaluation SDKs, targeting rules, or an admin UI, use a feature-flag platform instead.