Eloquent Repository Laravel Package

Product Decisions This Supports

• Architecture: build vs. buy for the data-access layer. Adopting jetcod/eloquent-repository is a decision to standardize the repository pattern across teams rather than hand-rolling interfaces per service. The package buys convention and a maintained base class; it does not buy query-building, caching, or domain logic — those remain ours.
• Feature work that benefits: multi-source or swappable persistence (e.g. read from an API or legacy DB behind the same interface as Eloquent), test suites that need fast model-free fakes, and large domains where controllers/services should not touch Eloquent directly.
• Framework upgrade roadmap. 1.7.0 aligns the package with Laravel 12 and 13. If our platform roadmap targets those versions, this release is a prerequisite enabler; if we are still on Laravel 8–11, this release is explicitly out of scope for us until we upgrade.
• Runtime baseline decisions. The PHP 8.1 floor and Carbon 3 requirement are environment commitments. Carbon 3 in particular can propagate to other dependencies, so this feeds into the wider PHP/dependency modernization plan, not just this package.
• Use cases to evaluate against: admin/back-office CRUD services, reporting read-models, and any module where we expect to swap or wrap the persistence mechanism within 12–18 months. For straightforward CRUD with no swap expectation, the abstraction cost likely outweighs the benefit.

When to Consider This Package

Consider it when:

• We are on, or committed to, Laravel 12/13 and PHP 8.1+ — the only supported combination as of 1.7.0.
• The codebase has (or will have) more than one persistence path per aggregate, or tests that would materially slow down if they hit a real database.
• We want a shared, documented repository contract across several teams rather than N subtly different implementations.
• We value predictable framework-cadence maintenance — the CI matrix running through PHP 8.5 and support landing for Laravel 12/13 are reasonable signals of active upkeep; still confirm maintainer responsiveness, issue throughput, and release history before committing.

Look elsewhere when:

• We are pinned to Laravel 8–11, PHP 7.4/8.0, or Carbon 2. Migrating those is a platform program, not a package bump; do not let a repository-pattern preference drive a framework upgrade on its own.
• The domain is simple CRUD — Eloquent models plus query scopes are adequate, and a repository layer adds indirection with no payoff.
• We need advanced query composition, caching, or multi-tenancy out of the box. This package is an abstraction seam, not a query toolkit; scope that gap explicitly.
• The team lacks appetite for the upgrade treadmill: 1.7.0 drops four Laravel majors at once, which is the pattern to expect on future majors.

Migration risk for existing adopters: the notes state no application-facing repository APIs changed, so source-level migration effort is expected to be low. The real cost is environmental — PHP, Laravel, and Carbon 3 upgrades plus a full regression pass. Pin ^1.7 deliberately and sequence it with the platform upgrade, not ahead of it.

How to Pitch It (Stakeholders)

For executives: This is a small, focused library that gives our Laravel services a consistent, testable boundary between business logic and the database. The new 1.7.0 release is a maintenance release — it keeps the package current with the newest Laravel versions and modern PHP, with no change to the interfaces our code uses. It carries no new product capability and no licensing cost; the decision it informs is an architecture standard, not a feature bet. The one real constraint: 1.7.0 requires Laravel 12/13 and PHP 8.1+, so it should be sequenced with our existing platform upgrade rather than triggering one.

For engineering: 1.7.0 drops PHP 7.4/8.0, Laravel 8–11, and Carbon 2; minimum is now PHP 8.1 with Carbon 3. No application-facing repository APIs changed, so adoption is an environment bump plus regression testing — the Carbon 3 constraint is the item most likely to cascade into other dependencies, so check the lockfile early. Upside: an actively maintained base (CI through PHP 8.5, Laravel 12/13 support) means we are not adopting an abandoned seam. Recommendation: standardize on it for modules with a credible persistence-swap or test-speed need, skip it for plain CRUD, and pin ^1.7 alongside the Laravel upgrade ticket.