Eloquent Builder Macros Laravel Package

Product Decisions This Supports

• Developer velocity on internal/admin surfaces. Packages in this category are pure DX sugar for the query layer — shorthand for whereLike, whereAny/orWhere groups, date-range and whereBetween filters, conditional when() chains, sorting helpers. The product value is time saved building filter bars, search endpoints, and reporting screens, not new user-facing capability.
• Build vs. buy (and the answer here leans "build"). The surface area of an Eloquent macro package is typically a single service provider plus a handful of closures. That is roughly a half-day of engineering to reimplement in App\Support\QueryMacros and register in AppServiceProvider. Buying introduces a dependency for code you could own outright.
• Roadmap fit: enabler, not a feature. Treat it as an implementation detail inside an epic like "Self-serve reporting" or "CRM filtering." It should never appear on a roadmap or in a customer-facing commitment — nothing about it is defensible or differentiating.
• Standardization decision. If adopted, it becomes a house style for every query in the codebase. That is the real PM-level question: do you want one blessed way to express filters? Native Laravel (whereAny, whereAll, whereNone, whereLike in recent versions) already provides much of this, which weakens the case for a third-party layer.
• Risk posture / supply chain. Zero stars, zero dependents, no release history to speak of, and a score of 0 means no community validation. For a commercial product this is a "vendor the code" decision, not a "require it in composer.json" decision.

When to Consider This Package

Consider it when:

• You are on a Laravel version predating the native whereAny/whereLike helpers and want those ergonomics now.
• You have read the source (it should take under ten minutes — that is the whole package) and the macros are trivial, side-effect free, and non-conflicting with framework or other package macro names.
• You are prototyping an internal tool where speed beats longevity, and you are comfortable forking later.
• You want a reference implementation to copy from rather than a runtime dependency.

Look elsewhere when:

• Maintenance and governance matter. No stars, no dependents, no evident CI or release cadence means abandonment risk sits entirely with you. For anything with a multi-year support horizon, that is a hard no as a require.
• You need declarative API filtering. If the real need is "let clients filter, sort, and include relations safely from a URL," reach for a mature, documented solution (e.g. spatie/laravel-query-builder) or write an explicit allowlist layer. Macro packages do not solve request-to-query safety.
• You need documented behavior. A macro's semantics (null handling, LIKE escaping, case sensitivity, SQL dialect differences) are exactly where bugs hide. Undocumented sugar in a query layer is a debugging tax on the next engineer.
• You already have the framework helpers. On current Laravel, several of these macros are redundant; adding a dependency to duplicate core behavior is negative value.
• Security or compliance review is required. Unexamined transitive dependencies are the cheapest thing to say no to.

Recommended path: copy the macros you actually use into first-party code, cover them with a handful of query-assertion tests, and skip the dependency. Keep the composer entry only if the author ships tagged releases and you want upstream fixes — which, at present, there is no evidence of.

How to Pitch It (Stakeholders)

To executives: "This is a small utility library that makes database queries slightly faster to write. It has no adoption, no maintainers of record, and no user-visible impact. Recommendation: do not add it as a dependency; if a team wants the helpers, we spend half a day writing them ourselves and own them permanently. Cost of the decision either way is negligible — the value is avoiding an unmaintained third-party link in our stack."

To engineering: "It's a service provider that registers Eloquent builder macros — read it in ten minutes. Two concerns: (1) macro name collisions are global and silent, so namespace anything we adopt with a prefix; (2) several of these now duplicate native whereAny/whereLike, so check the Laravel version matrix first. Proposal: lift the two or three macros we actually use into App\Support\QueryMacros, add query-assertion tests, and move on. If we do take the dependency, pin it exactly and add it to the quarterly dependency review."

To design/QA: "No customer-facing behavior changes. Query results should be identical; the only test surface is that filters return the same rows and respect null and empty-string semantics the same way the current code does."