Product Decisions This Supports
- Build vs. buy for query-layer sugar. Every Laravel codebase eventually accretes a
app/Support/ModelMacros.php or a HasCustomQueries trait full of whereLike, JSON-path, and ordering helpers. This package is the buy-side answer to that: a maintained, versioned home for those Eloquent builder extensions instead of an unowned internal file that rots between framework upgrades. The decision this release supports is "adopt the package and delete the internal trait," not "write our own."
- Framework upgrade sequencing. 3.5.0 explicitly adds declared support for Laravel 13 and PHP 8.5, plus PHPUnit 12 in the test matrix. That is the single most decision-relevant fact here: it means this dependency is not a blocker on our next framework/PHP upgrade train. A PM can treat it as cleared in the upgrade readiness checklist rather than as an open risk to schedule work around.
- Roadmap timing / cost of upgrade. 3.5.0 contains no functional changes — no new macros, no behavior changes, no deprecations, no breaking changes. The upgrade decision is therefore cheap: bump the constraint, run the suite, ship. It should be batched into routine maintenance, not given its own backlog item.
- Test-infrastructure modernization. PHPUnit 12 support means the package's own guarantees remain verifiable on our target test runner; it also signals the maintainer is tracking the tooling chain, which is a proxy for project health when we assess other small dependencies with the same rubric.
- Consistency use case. The core product value is uniform query expression across teams and models — fewer
DB::raw() escapes, fewer subtly different LIKE/collation implementations per squad, and reviewable Eloquent chains instead of hand-rolled SQL fragments.
When to Consider This Package
Adopt when:
- Multiple models/services need the same set of non-core query helpers, and you're currently duplicating them or growing an internal macro trait.
- You are on, or actively planning, Laravel 13 / PHP 8.5 / PHPUnit 12 and want one fewer dependency to audit during that migration.
- Your data layer is conventional Eloquent over MySQL/Postgres and you want the helpers to be a pinned, versioned dependency rather than copy-pasted code.
- You want a zero-config, drop-in package — this is a macro library, not a framework; there is no new abstraction to learn or architecture to defend.
Look elsewhere (or skip) when:
- You need only one or two helpers. Inline them as local scopes; a dependency for two methods is a net cost in audit surface.
- Your workload is analytics/reporting-heavy. Builder macros don't fix query shape, indexing, or read-model design — that's a separate architectural decision.
- You require vendor SLA, security response commitments, or multi-maintainer bus factor. This is a single-maintainer package; the dependabot-heavy changelog shows automated hygiene, not institutional backing.
- Your team leans on static analysis and IDE-discoverable APIs. Dynamic macros are opaque to
larastan/autocomplete; explicit local scopes may be the better product trade for onboarding and refactor safety.
- You need documented cross-database portability guarantees beyond what your tested engines cover.
Adoption gate: pin to ~3.5, confirm the Laravel 13 constraint matches your actual framework version before relying on it, and record the package as a low-risk, single-maintainer dependency in the risk register so it gets re-reviewed (not silently inherited) at the next major upgrade.
How to Pitch It (Stakeholders)
To executives (one paragraph): We're standardizing a small, low-risk Laravel dependency that replaces code we write and maintain ourselves. The new 3.5.0 release is maintenance-only — no behavior changes — but it confirms the library is already compatible with the next versions of Laravel (13), PHP (8.5), and our test runner (PHPUnit 12). That converts a recurring internal maintenance cost into a versioned dependency someone else keeps current, and it removes this component from the list of things that could delay our next platform upgrade. Cost of adoption is a constraint bump and a test run.
To engineering (one paragraph): zingimmick/laravel-eloquent-extensions 3.5.0 is a safe minor: no functional changes, no deprecations, no breaking changes — the diff is compatibility work (Laravel 13, PHP 8.5, PHPUnit 12) plus routine CI dependency bumps. It's a drop-in macro package, so the trade is explicit: less duplicated query-helper code across models, in exchange for query behavior that lives in a third-party package and is invisible to static analysis. Plan: pin ~3.5, verify the Laravel 13 constraint against our actual framework version, run the suite, and prefer explicit local scopes where a helper is used in only one place. Note the bus factor — one maintainer — and keep the pin tight.