Utils.common.sortable Interface Laravel Package

Technical Evaluation

Architecture fit. This package is a single-interface artifact from the Mouf framework ecosystem (thecodingmachine), not Laravel. Its entire contract is "an object implements sort($key, $direction)." In a Laravel codebase, sorting is expressed idiomatically through Eloquent (orderBy, query scopes, reorder) or Collections (sortBy, sortByDesc, non-mutating return-a-new-instance semantics). The package's contract does not align with either: it implies an in-place mutation, exposes no return type, and takes an untyped $key (a column name) and $direction — precisely the two values Laravel developers normally route through a server-side allowlist before touching the query builder. Adopting it would push a foreign, Mouf-flavored abstraction into the domain layer for zero functional gain.

Integration feasibility. Mechanically trivial: MIT-licensed, Composer-installable, PSR-4 autoloadable, no runtime dependencies, no service provider, no config, no migrations. The real feasibility question is not "can we install it" but "should this class name appear in our dependency graph." At 1 star, 0 dependents, and a last release of 2017-05-17, the package has effectively no ecosystem validation — the composite score of 0.005 and opportunity signal of 45.45 should be read as discovery noise, not as latent value.

Technical risk.

• Supply chain / build risk (medium). Mouf-era packages frequently declare mouf/installer or similar Composer plugins to register themselves with the Mouf container. Under Composer 2.2+ these are blocked by allow-plugins, which surfaces as interactive prompts or hard failures in CI. This must be verified in composer.json before any composer require.
• Contract ambiguity (medium). No return type, no direction enum, no declare(strict_types=1). Consumers cannot know whether sort() returns void, $this, or a sorted copy — a real source of inconsistency across a multi-team codebase.
• Injection-adjacent surface (medium). A public sort(string $key, ...) invites callers to pass user input as a column name. The interface cannot enforce an allowlist; every implementer must remember to. That is a latent SQL-error/injection foot-gun encoded as a feature.
• Abandonment (low impact, high optics). No release in eight years. Because the artifact is a frozen interface, drift risk is near zero — but the appearance of an unmaintained dependency in an audit or vendor review is a cost with no offsetting benefit.
• Security exposure (negligible). Interface-only, no executable code; composer audit and SCA tooling will find nothing.

Key questions.

1. What is the exact FQCN and PSR-4 root, and does it load cleanly without any Mouf bootstrap or container?
2. Does composer.json require a Composer plugin (mouf/installer or equivalent)? If yes, this is a non-starter for our CI.
3. What are the legal values of $direction — 'ASC'|'DESC', 'asc'|'desc', or booleans? Is it case-sensitive?
4. What does sort() return, and is mutation or copy semantics intended?
5. Who enforces the column allowlist — the caller, the implementer, or nobody?
6. Is there any internal consumer, or is this greenfield?

Integration Approach

Stack fit. Poor. PHP-7-era, untyped signatures against a Laravel 10/11 runtime (PHP 8.1+) means the package installs fine but reads as legacy. It also conflicts conceptually with Collection sortBy semantics and with Eloquent's builder, so we would end up maintaining adapters to bridge a contract we don't need.

Migration path. There is nothing to migrate — no data, no schema, no state. The correct path is build, don't buy: define a local contract in app/Support/Contracts/Sortable.php (roughly twelve lines) with modern typing, e.g. public function sort(string $key, string $direction): static;, plus a SortDirection enum and a SortableWhitelist trait that validates $key against $sortable before it reaches orderBy. Cost: under a day. That also gives us reviewability and a place to hang the allowlist enforcement.

Compatibility. Only meaningful if we accept the Mouf lineage: verify Composer 2.x plugin allowances, confirm no container coupling, confirm autoload works standalone. If any of those checks fail, the package is unusable regardless of merit.

Sequencing.

1. Now (decision): Reject as a dependency. Log the FQCN in the architecture decision record with the rationale "trivial, unmaintained, non-idiomatic."
2. Sprint N: Author the local Sortable contract + enum + whitelist trait in the shared support library.
3. Sprint N+1: Retrofit any model/service that needs the capability; add a static-analysis rule or review checklist banning raw column names in orderBy.
4. Optional, if a hard portability requirement emerges (e.g. a shared package across a non-Laravel app): revisit an interface-only extraction from our own code, not from this package.

Operational Impact

Maintenance. Upstream is dormant — no releases since May 2017, no responsive maintainer. Paradoxically, a frozen interface is close to zero-maintenance: it cannot break, because it does nothing. The cost is entirely in cognitive and governance overhead — every new engineer who sees Mouf\...\SortableInterface in composer.json must investigate an unfamiliar framework to conclude it is inert. That is a permanent, small tax for a temporary convenience.

Support. None. One star, zero dependents, no issue activity. Internal on-call will be the effective maintainer of any behavior we build on it — which argues for owning the twelve lines ourselves.

Scaling. No runtime cost: no code executes, no I/O, no memory. It will not affect request latency, queue throughput, or horizontal scaling at any volume. The scaling concern is organizational: an unmaintained dependency in a platform shared by many teams multiplies the "is this safe?" question across every consuming team.

Failure modes.

• Build/CI failure from blocked Composer plugins — high visibility, easy to diagnose, but blocks the pipeline until allow-plugins is negotiated.
• Contract misuse — a caller passes $request->input('sort') directly as $key; the implementation interpolates it into a query and produces a SQL error or, depending on the driver, worse.
• Direction drift — one implementer expects 'desc', another 'DESC', a third true. Manifests as silently wrong ordering, which is the worst class of bug: it looks like data, not like code.
• Governance flag — an audit or acquirer's diligence surfaces an eight-year-stale thecodingmachine dependency in a Laravel stack and asks why. There is no good answer.

Ramp-up. Effectively instantaneous for the interface itself — a competent PHP engineer understands sort($key, $direction) in seconds. The non-trivial ramp is on the surrounding conventions: whether the column name is trusted, what the direction vocabulary is, and whether the operation mutates. Those gaps are exactly what the package does not solve, and exactly what a local contract would.

Recommendation. Do not adopt. The package is a 2017 single-interface artifact from a framework we don't use, with no dependents and no maintenance, offering a contract we would have to constrain, wrap, and document before it was safe. Reimplement the pattern locally with strict types, a direction enum, and an enforced column allowlist; record the rejection and move on. Adoption is only defensible if a hard requirement exists to interoperate with a third-party Mouf-based library — and even then, a local adapter implementing our own interface, with the dependency confined to that adapter, is the better boundary.