Laravel Wherehasin Laravel Package

Product Decisions This Supports

• Performance triage on read-heavy list/filter surfaces. This is not a feature; it is a query-shape optimization. It matters if your product has admin panels, dashboards, exports, or CRM-style filter screens that ask "show me parents that have a matching child" — e.g. customers with an order over $X in the last 30 days, accounts with no login in 90 days, projects with an overdue task. Those are whereHas / doesntHave queries, and on MySQL with large child tables they are a classic cause of p95 latency spikes and dashboard timeouts.
• Build vs. buy vs. fork. The "buy" is close to free (MIT, tiny surface area, likely a macro or trait). The honest recommendation is neither buy nor build from scratch: vendor the pattern. If benchmarks show the win, ask engineering to implement it as an in-house query-builder macro rather than take a dependency. That preserves the benefit and removes the maintenance risk.
• Prioritization input, not a roadmap item. This never appears on a customer-facing roadmap. It is a maintenance/tech-debt line item competing against caching, indexing, read replicas, and denormalization. Fund it only where the measured cost of slow queries (support tickets, timeout error rate, report abandonment, DB CPU spend) exceeds a day or two of engineering.
• Deciding whether to invest in the query layer at all. Use it as a forcing function: before adopting, get EXPLAIN output on the top 5 slowest list endpoints. If the bottleneck is a missing index or an unindexed join column, this package buys you nothing and you should spend the sprint elsewhere.
• Scope of use cases it does not cover. It does not fix N+1 (that's eager loading), it does not help when you need the related models returned (that's with()), and it does not help on Postgres, where the planner generally handles EXISTS semi-joins well. Set expectations accordingly so it doesn't get pitched internally as a general performance fix.

When to Consider This Package

Consider it when:

• You are on MySQL/MariaDB, and EXPLAIN shows dependent/correlated subqueries for existing whereHas / doesntHave filters on large child tables.
• You have a small, well-understood set of slow queries you can benchmark in staging with realistic data volumes — before/after query time and EXPLAIN, not vibes.
• You are on Laravel 8 or earlier, where the package is most likely to still install cleanly, or you are prepared to fork it (it's MIT, and the change is small enough that a fork is cheaper than a support negotiation).
• The filter is existence-only — you need the parent rows, not the children.
• You can absorb the QA cost of verifying result parity. whereHasIn rewrites query semantics; edge cases around soft-deleted children, custom relation keys, polymorphic relations, and mixing with orWhere need regression coverage. That test work is the real adoption cost, not the install.

Look elsewhere when:

• You're on Laravel 10/11/12. Last release was July 2021. Four-plus years without a release is a hard signal. Even if the code still works, you're relying on an unmaintained package for correctness in money-adjacent reporting queries. Fork or reimplement.
• The root cause is missing indexes, bad schema, unbounded date ranges, or a missing cache layer. Fix those first — they're usually larger, cheaper wins.
• You need Postgres support or cross-database portability.
• The child subquery can return a very large row set. IN (subquery) can be slower than a semi-join in that regime; MySQL version and data distribution matter. Never adopt this as a blanket rule.
• The organization has a policy against single-maintainer micro-dependencies. 247 stars and no dependents in the registry is not ecosystem validation — treat the author's reputation (jqhph is well known in the Laravel China community, creator of Dcat Admin) as the only real signal, and note that reputation doesn't ship patches.

How to Pitch It (Stakeholders)

For executives — one paragraph: "This is a small, free, open-source performance patch for a specific class of slow database queries behind our admin and reporting screens. It is not a customer-facing feature and should not be funded as a project. The recommendation is to spend one engineering day benchmarking it against our five slowest list endpoints; if it produces a meaningful latency improvement, we reimplement the technique in-house (about a day of work) rather than depend on a package that hasn't been updated since 2021. Expected outcome: lower p95 on reporting screens and fewer 'the dashboard is timing out' tickets, at effectively zero licensing cost. If benchmarking shows no win, we spend that day on indexes instead."

For engineering:

• The package rewrites where exists (select …) into where id in (select …), which lets MySQL use semi-join strategies instead of re-evaluating a correlated subquery per row.
• It's MIT and small — treat it as reference implementation, not a dependency. Port the macro into our query builder, add tests for soft deletes, custom keys, and orWhere combinations, and own it.
• Gate adoption on measurement. Bring EXPLAIN before/after and p50/p95 timings on staging with production-scale row counts. If the gain is under ~20% on any query, drop it.
• Flag: unmaintained since 2021, single maintainer, no meaningful dependent base. Under our supply-chain policy that's a fork-or-skip, not an install.
• Rough sizing: half a day to spike, one to two days to port and test. No schema migrations, no runtime dependencies, trivially reversible.