Contracts Laravel Package

Product Decisions This Supports

• Build vs. buy on abstraction plumbing. Interfaces for caching (Cache\Store, Cache\Ttl), queues (ShouldQueue, ShouldBeUnique), DTO conversion (Dtoable), HTTP domain helpers (Http\Builder), actions, and migrations are low-differentiation work. This package is a candidate to skip writing them ourselves — but see the archived-status caveat below before committing.
• Architecture standardization across squads. A shared contract set gives product and platform teams one vocabulary for cross-module boundaries, which shortens design reviews and reduces "two teams, two interfaces for the same concept" drift in a modular monolith or multi-service Laravel estate.
• Package and platform roadmap. If we ship internal Composer packages or a shared service template, contract-only dependencies keep consumers decoupled from our implementations, so we can version implementations without forcing downstream rewrites.
• Framework-upgrade planning. The release history shows deliberate Laravel 11 and 12 plus Symfony 6/7 tracking. That is a useful signal for roadmap items gated on framework currency — though the archive status means we now own that tracking going forward.
• Test strategy and CI reliability. Coding against interfaces rather than concretions makes cache, queue, and HTTP collaborators mockable, which supports an investment case for reducing flaky integration tests. Treat the payoff as directional, not a number to put in a business case.
• Vendor and dependency risk review. Ten stars, zero dependents, and an archived repository are themselves a product decision input: any adoption needs an explicit position on who maintains the interfaces if the upstream stops.

When to Consider This Package

Reasonable to evaluate when:

• We are on Laravel 11/12 (or a Symfony 6/7 stack) and are actively standardizing interfaces for cache, queue, DTO, or HTTP concerns across more than one codebase.
• We are standing up a modular monolith or internal package set and want a ready-made, MIT-licensed starting point for the contract layer rather than a blank file.
• We already depend on DragonCode tooling (e.g. dragon-code/helpers) and want type compatibility with Dtoable and friends.
• We want a reference catalogue of interface shapes — reading or vendoring the definitions is lower risk than depending on them.

Look elsewhere when:

• Maintenance continuity matters. The repository is archived. There is no upstream to absorb Laravel 13+ or Symfony 8 changes. A hard dependency on an archived, single-maintainer package needs an owner, a fork plan, and a pinned version — otherwise prefer Laravel's own contracts or PSR interfaces.
• Adoption signal matters for a build-vs-buy call. Zero dependents and minimal stars means almost no field validation; we would effectively be the first real consumer and would find the rough edges ourselves.
• We need implementations. This package ships interfaces only; Redis drivers, migration logic, and job plumbing are still ours to write.
• The team's conventions are trait- or base-class-driven, or the codebase is small enough that a handful of hand-written interfaces is cheaper than a dependency plus its governance.
• We need domain-specific contracts, legacy-system boundaries, or backward-compatibility guarantees for a public API — none of which this collection covers.
• We are on Laravel 10 or older; the recent release line targets 11/12.

How to Pitch It (Stakeholders)

For executives — the honest one-paragraph version: This is a small, MIT-licensed library of PHP interfaces for the repetitive parts of our Laravel stack — caching, queues, data transfer, HTTP helpers. Its value is consistency and speed, not capability: it saves us from writing and re-litigating the same interfaces in every service, and it makes components swappable and testable. Two caveats belong in the same breath. First, it adds no runtime behavior — it is type definitions only, so there is no performance cost and no new failure mode. Second, the project is archived and has essentially no external adoption, which means the moment we adopt it we should be prepared to own a fork. Recommendation: adopt the pattern, and only take the dependency if engineering accepts a named owner and a pinned version. I would not present this as a cost-saving initiative with an attached percentage; the benefit is developer time and architectural coherence, and it should be justified on that basis.

For engineering and architecture leads: The package gives us pre-written, framework-current interfaces for the concerns we keep re-implementing: Cache\Store and Cache\Ttl (including rememberForever and doesntHave semantics), Queue\ShouldQueue and ShouldBeUnique, Dtoable for serialization-agnostic DTOs, Http\Builder domain helpers, plus action and migration contracts. That supports dependency inversion, makes cache/queue/HTTP collaborators straightforward to fake in tests, and gives cross-team packages a shared vocabulary instead of three subtly different CacheInterface definitions. The counterarguments are concrete: the repo is archived, so Laravel 13 compatibility is on us; there are no dependents to lean on for battle-testing; and the API surface has historically moved in small increments, so pin the version and review changelogs on upgrade. Suggested path: vendor the interfaces we actually use into an internal platform/contracts package (MIT permits this), keep the names close to upstream so we can re-sync if the project revives, and use the upstream repository as design input rather than a live dependency. That captures the standardization benefit, removes the single-maintainer risk from our critical path, and leaves the door open either way.