Hasin Laravel Package

Product Decisions This Supports

• Performance remediation of relationship filters. hasin swaps Eloquent's correlated EXISTS subqueries (from has() / whereHas()) for whereIn-style queries against the related table's keys. This is a targeted lever for endpoints where whereHas shows up in slow-query logs — typically paginated index screens, admin dashboards, search/filter UIs, and CSV/report exports.
• Build vs. buy on a tiny surface area. The capability is small enough to hand-roll (a query scope or local macro). Buying is defensible because it is maintained across framework majors and handles the fiddly cases (nested relations, morph relations) that in-house scopes tend to get wrong.
• Roadmap / upgrade sequencing. v5.1.0 adds Laravel 13.x compatibility. That is the entire substance of this release — it removes a blocker from the framework upgrade train rather than adding product capability. Plan it as a dependency bump alongside the Laravel 13 upgrade, not as a standalone initiative.
• Risk register entry for third-party dependency posture. The release is almost entirely Dependabot noise plus one compatibility PR from laravel-shift. That pattern is "quiet and maintained," not "actively developed." Record it as such so it isn't re-litigated every upgrade cycle.
• Use cases to scope in: API index endpoints with ?filter[relation]= parameters, "customers with at least one overdue invoice" style segment builders, and any listing where the relationship table is large relative to the parent table.
• Explicitly out of scope: domain modeling, schema design, authoring UX, and anything where the decision hinges on relationship counting semantics rather than existence filtering.

When to Consider This Package

Adopt when most of the following hold:

• You have measured a problem: EXPLAIN or APM shows correlated subqueries on a relationship filter dominating a hot path, and the related table has enough rows that the planner's row-by-row evaluation hurts.
• Your workload is read-heavy and paginated — the shape where whereIn on an indexed foreign key consistently beats EXISTS.
• You need nested and polymorphic relationship filtering without writing bespoke join logic.
• You are on a currently supported Laravel major (v5.x line; v5.1.0 is the version that covers 13.x).
• Your constraint patterns are simple enough to translate — validate your actual closures first.

Look elsewhere or defer when:

• The dataset is small. Native has() / whereHas() is correct, zero-dependency, and fast enough. Adding a package here buys nothing.
• Your filters rely on constraints that reference the parent table or use complex aggregates inside the subquery. Semantics can diverge; prototype against your real queries before committing.
• You need deep multi-hop relationship traversal — reach for staudenmeir/eloquent-has-many-deep instead of stretching this one.
• You need withCount-style aggregates, not existence filtering.
• You are on an older Laravel major — pin the matching line rather than assuming 5.1.0 applies.
• A single-maintainer dependency is a policy violation for you. That is a legitimate call given the contributor profile; mitigate by isolating it behind your own scope.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small, free, open-source Laravel package that makes one common type of database query substantially cheaper. It targets list-and-filter screens that slow down as data grows — the ones users complain about and that drive database load. There is no license cost, no vendor relationship, and it is a handful of lines to adopt. The v5.1.0 release is a compatibility update for the next Laravel version, with no breaking changes, which means it stays viable through our planned framework upgrade rather than becoming upgrade debt. Risk is low and reversible.

For engineering (the actual argument): Thin API surface, drop-in, and it removes correlated subqueries from our hottest filter paths. Two caveats to own up front: it is effectively single-maintainer, and release velocity is low — this version is Dependabot bumps plus a Laravel 13 compatibility fix. That is a maintenance signal, not a red flag, but it means we should not depend on upstream for roadmap. Mitigations: wrap it behind our own Eloquent scope so the call sites are ours, pin the version, and add a benchmark plus query-count assertion to CI so a future swap is a one-file change. Also verify our specific whereHas closures translate correctly — especially anything referencing the parent table.

The ask: Approve a one-sprint spike — adopt in a single read-heavy service, benchmark before/after against one real endpoint, and report. Roll forward or revert on the numbers.