Laravel Sorting Laravel Package

Product Decisions This Supports

• Framework upgrade planning (Laravel 12 → 13): 0.1.11 replaces the deprecated Request::get() with input(), keeping the package clean on symfony/http-foundation 7.4 / Laravel 13. This is a dependency-health signal for roadmap decisions about when the platform can move to Laravel 13 — a sorting package still calling get() would otherwise add deprecation noise or become an upgrade blocker.
• Reliability / error-budget decisions: malformed input such as ?sort[]=x now falls back to the default sort instead of throwing a TypeError (a 500). That converts a user-triggerable server error into graceful degradation — directly relevant to error-tracking noise, SLOs, and whether public list endpoints can accept arbitrary query strings.
• Build vs buy for query-param handling: scope here is narrow (parse and apply a sort parameter). It's a defensible "buy" only while the package keeps absorbing framework churn and edge cases like these two; if maintenance lags, in-housing is a small, contained effort.
• Feature/use case fit: read-heavy index endpoints, admin tables, and API list endpoints needing ?sort=field / ?sort=-field semantics. Not sufficient on its own for multi-key ordering with per-user persisted preferences.

When to Consider This Package

Adopt when:

• You want consistent sort-parameter handling across many list endpoints instead of re-implementing it per controller.
• You are on, or preparing for, Laravel 13 / Symfony 7.4 and want dependencies that are already deprecation-free.
• Endpoints are publicly reachable and you want array/malformed query input handled gracefully rather than 500-ing.
• You accept 0.x semver: pre-1.0, so minor releases may carry behavior changes — pin versions and read release notes.

Look elsewhere (or build in-house) when:

• Sorting needs are complex: relation-aware sorting, weighted multi-key ordering, or interplay with cursor/keyset pagination. A thin sort parser likely won't cover it.
• You need a stable public API plus vendor support/SLA; a 0.x line with a small release cadence adds upgrade overhead.
• Silent fallback is wrong for your product: if bad sort params must return a 422 rather than quietly defaulting, you'll need to wrap or replace this behavior.
• Your framework baseline is older and you don't want forward-compatibility churn.

How to Pitch It (Stakeholders)

Executives: This is a maintenance-grade release, but the right kind — it keeps us current with Laravel 13 and stops malformed requests from producing server errors. Small effort, lower upgrade risk, less error noise.

Engineering: 0.1.11 stops using Request::get() (deprecated in symfony/http-foundation 7.4, shipped with Laravel 13) in favor of input(), and coerces non-string sort values — e.g. ?sort[]=x — to the default sort instead of raising a TypeError. No caller-facing API change. Two caveats: we're on a 0.x line, so pin the version and watch minor releases; and the fallback is silent, so if we want client-visible validation on bad sort params we must add it ourselves.