Utils.common.sortable Interface Laravel Package

Product Decisions This Supports

• API/list-endpoint contract design. The package's entire surface is a capability contract: "this object can sort itself given a key and a direction." That is the decision it informs — whether to standardize how sortable collections are expressed across your codebase (admin data grids, report builders, CSV exports, paginated API resources) rather than letting each feature invent its own sortBy/orderBy signature.
• Build vs. buy: this is a "neither." There is nothing to buy or build here — it is roughly one interface with one method. The real decision is convention adoption: do you codify one internal Sortable interface, or leave sorting semantics implicit in each service?
• Roadmap input on sorting/filtering features. If sorting is on the roadmap for multiple surfaces, a shared contract is a prerequisite for consistent behavior (direction validation, null handling, tie-breakers, whitelisted keys). This package does not solve any of those — it only names the concept — so it should be treated as a naming precedent, not a dependency that de-risks the roadmap.
• Interop scoping inside the Mouf/TheCodingMachine ecosystem. Its only defensible value is if you already run Mouf/Splash/TDBM components that type-hint against Mouf\Utils\Common\SortableInterface. Outside that stack the interoperability value is zero (0 dependents, 1 star, last release 2017-05-17).
• Supply-chain and maintenance posture. A 2017-vintage, zero-dependent, one-star package is a signal to prefer vendoring the idea over adding the dependency — a decision point about dependency hygiene more than about functionality.

When to Consider This Package

Adopt it only when all of the following hold:

• You are maintaining or integrating a Mouf-framework application or a package whose public API already type-hints Mouf\Utils\Common\SortableInterface, and swapping the type would break third-party components.
• You need the interface to be shared across two or more packages you don't control, so a local class would create incompatible duplicate contracts.
• You have verified it installs cleanly under your PHP version (no release since May 2017 — expect unconstrained or stale php requirements and no PHP 8.x/enum-era type safety) and that your autoloading handles it.
• You are comfortable treating it as frozen, unmaintained code that you may need to fork or pin.

Look elsewhere — or write three lines yourself — when:

• You are building a modern Laravel application. Laravel already owns this problem: query-builder orderBy, Eloquent scopes, and mature packages like spatie/laravel-query-builder handle request-driven sorting, key whitelisting, and direction validation. An interface that says "I can sort" adds no enforcement and no behavior.
• You want direction safety. There is no enum or typed direction here; a local SortDirection enum plus a Sortable interface gives you static-analysis guarantees this package cannot.
• Social proof or support matters. One star, zero dependents, no commits in ~8 years means no community answers, no security response, and no bug-fix path — for a package whose content you could reproduce in a single file.
• You care about stable public contracts. If the interface lives in your own namespace, you control its evolution (adding sortMany, tie-breakers, whitelist validation); if it lives in an abandoned vendor namespace, you inherit its constraints forever.

How to Pitch It (Stakeholders)

To executives: This is a single-interface utility with no functionality, no adoption (one star, zero dependents), and no maintenance since 2017. It carries effectively zero license cost (MIT) and equally zero business value. Recommendation: do not add it as a dependency. If we want a standard "sortable" contract, engineering can define one internally in under an hour, with better type safety. The strategic takeaway is a governance one — our dependency review caught an abandoned micro-package before it entered the tree.

To engineering: Treat this as a naming precedent, not a library. Define App\Contracts\Sortable with sort(string $key, SortDirection $direction): static, back it with an enum, enforce it via PHPStan, and let Eloquent/spatie/laravel-query-builder own the actual ordering and key-whitelisting. Only take the vendor package if you're inside Mouf and an existing component already type-hints it — in which case pin it, expect no upstream fixes, and plan to fork.