Laravel Utils Laravel Package

Product Decisions This Supports

• Build vs. buy — this one still resolves to "neither, vendor it." The v1.2 release adds a Sortable trait (a Livewire list-sorting helper), but it does not create an upstream to buy from or a vendor relationship to manage. One release is a data point, not a maintenance commitment — we have no evidence of a cadence, a security contact, or downstream users exercising the code. The MIT license remains the only durable asset: a clean legal path to copy the pieces worth keeping into app/Support or an internal package, with attribution.
• One genuinely new capability to evaluate: Livewire list sorting. This is the first item in the package that touches a framework surface we actually use rather than generic PHP helpers. Sorting is a recurring, low-differentiation need in admin tables and dashboards, so it is worth a look — but it is also the kind of helper that is 30–60 lines and that we would want to own outright, because sort behavior is where user-supplied parameters meet our query layer.
• Feature scoping shortcut for greenfield Laravel work. The package remains a curated list of primitives teams re-write. Reading the source is still a fast way to sanity-check our own list of helpers, query scopes, Blade directives, and validation rules before building them — useful sprint-0 input for an internal tool or client project.
• Roadmap signal, not a roadmap item. If Sortable-style helpers keep coming up across projects, that is a case for an internal laravel-support package we own with tests and a named owner — not a third-party dependency, and definitely not one whose release history is a single entry.
• A new review gate before any reuse: sort-input handling. Whatever we lift must whitelist sortable columns and directions against a declared allowlist. A sort helper that trusts request parameters is a data-exposure and query-cost risk on any customer-facing list, and we should assume nothing about the original's input handling until we read it.
• Anti-decision — keep it off the critical path. This should not appear on a product surface with an SLA, a customer-facing API, or a multi-year maintenance horizon. One release does not change the core risk: no confirmed maintainer cadence and no dependents means no one is watching for the next Laravel major, Livewire major, PHP minor, or CVE.
• Use cases where it's defensible: a timeboxed prototype, a throwaway internal admin tool, or a one-off migration script where replacing the helper later costs minutes. The Sortable trait fits this profile well — internal admin tables are exactly the low-blast-radius surface where a vendored helper is fine.

When to Consider This Package

Consider it as source material, not a dependency, when:

• You are on Laravel and Livewire versions the package's composer.json constraints actually cover — Livewire is now a real coupling point, not an incidental one, so verify both against our target versions rather than assuming. Note the package's Livewire support is unstated in the release notes; check the constraint before anything else.
• You need one or two specific pieces — realistically the Sortable trait, not the whole grab bag. Copying a trait and its column allowlist into app/Support is a short job; pulling in a package is a forever job.
• You can afford a timeboxed spike (half a day, hard stop) to read the source and judge quality. The v1.2 release is the only recent signal; assume no test coverage until proven otherwise, and specifically probe the sort-input path for allowlisting and direction validation.
• You are willing to own every line you take. Once vendored, it is our code, our style, our tests, our bug — plus our Livewire upgrade work.

Look elsewhere when:

• Procurement or supply-chain policy applies. Most orgs' dependency policies assume an active maintainer, a security contact, and a release cadence. One release does not evidence any of the three on inspection; treat the project as unmaintained until it demonstrably isn't.
• You need patch cadence. Laravel majors land roughly annually and Livewire majors land on their own schedule; a package with a single recent release will not reliably follow either. Budget for a fork we maintain or expect breakage on upgrade.
• The need is genuinely commodity. Laravel core (Str, Arr, Collection, Number), first-party packages, Livewire's own primitives, and well-maintained community packages (Spatie et al.) cover most of what a utility grab bag offers — with someone else on the hook for maintenance. Livewire sorting in particular has well-trodden implementations we can crib the design from without adopting code.
• The requirement is a documented, stable API. Near-zero downstream users means near-zero real-world exercise. Every edge case — nulls, related-column sorts, multi-column sorts, pagination interaction — is one we discover ourselves.

How to Pitch It (Stakeholders)

To executives (one paragraph): We re-reviewed a small, free, MIT-licensed Laravel helper library after a new release added a Livewire sorting helper. The new feature is genuinely relevant to us, but it does not change the underlying picture: the project has no demonstrated maintainer cadence, no downstream users, and one recent release after a long gap — so any bug or framework incompatibility becomes ours to fix. Because it is MIT-licensed, we can legally lift the sorting helper into our own codebase in about a day, with tests and an explicit column allowlist. My recommendation is unchanged: approve a short evaluation spike and hold a "no production dependency" position. The upside is small and concrete; the maintenance liability we avoid is open-ended.

To engineering (the ask): Please don't composer require this. Spend a half-day on the new Sortable trait specifically — check its Livewire version constraint, read the sort-input path, and confirm it whitelists columns and directions. If it's sound, vendor it into app/Support with the MIT notice, an attribution header noting the origin and version, an explicit allowlist, and tests covering nulls, related columns, and pagination interaction. If we ever do take it as a dependency, pin to a commit SHA, add it to the tech-debt register with a named owner, and set a reminder to revisit on the next Laravel or Livewire major. Expect the honest outcome to be "one useful idea worth reimplementing, nothing we need to ship."