Statamic Query Builder Laravel Package

Product Decisions This Supports

• List/table UX roadmap: The 3.4.0 release adds additional sorting options, which directly underwrites roadmap items like sortable columns, multi-column ordering, and default sort states on admin and customer-facing tables — without committing engineering to bespoke query-string handling.
• Build vs. buy: Sorting, filtering, and pagination plumbing is commodity work. Adopting the package converts a recurring per-screen engineering cost into configuration, freeing capacity for differentiating features.
• API contract decisions: Standardising a single sort-parameter convention across endpoints (naming, direction syntax, multi-key ordering) is a public API decision; the package sets that contract for us and keeps it consistent as new sort modes land.
• Internal tooling and autonomy: Expanded sorting support lets ops/analyst teams reorder and prioritise data views through configuration rather than filing tickets, reducing low-value backlog churn.
• Scope tradeoffs: Informs whether to invest next in saved views, per-user sort preferences, or export ordering — each becomes cheaper once sorting is declarative rather than hand-rolled.
• Security posture: Whitelisted, validated sort fields prevent arbitrary column ordering against the database; this is a product-risk decision made once, centrally, instead of per feature.

When to Consider This Package

Adopt when:

• You have multiple list endpoints or data tables that need consistent, predictable sorting behaviour.
• The team is already on Laravel and benefits from framework-native conventions over a custom abstraction.
• You need validated, allow-listed sort inputs (a common source of injection and performance bugs).
• You want additive, low-drama upgrades — 3.4.0 is a minor release with new sorting capabilities and no breaking changes or deprecations.

Look elsewhere when:

• You have a single table with a fixed sort order; the dependency overhead outweighs the benefit.
• You need relevance ranking, fuzzy matching, or faceted search — that belongs in a search engine, not a query-construction package.
• Your column-level permissions or multi-tenant model can't be expressed through the package's sort whitelisting without custom guards.
• You require computed or window-function-based ordering the abstraction can't express safely.
• Release cadence or maintainer activity has stalled — verify this before making it a load-bearing dependency.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk dependency that removes custom code from every list screen we build. Incremental releases like 3.4.0 hand us UX improvements — additional sorting options — that we would otherwise have to schedule and staff ourselves. It buys velocity at near-zero operational cost.

For engineering: Sorting is declared in configuration rather than reimplemented per controller. The 3.4.0 upgrade is additive only: new sorting options, no breaking changes, no deprecations — a routine version bump that can ride a normal maintenance window. It also centralises allow-listed sort fields, which removes a class of query-injection and full-table-scan bugs.

Risk framing: Additive minor release, low upgrade effort, reversible. Pin the version, upgrade on the standard cadence, and revisit only if maintainer activity declines or our sorting needs outgrow what declarative configuration can express.