- What is sbamtr/laravel-query-enrich used for?
- It is a developer-ergonomics helper that layers a fluent API over Laravel's Eloquent builder and query builder so you can append computed columns, conditional aggregates, and custom subqueries without leaving the fluent chain. The goal is richer results without extra queries or bloated model classes, and with query logic that stays reusable. It adds no service, queue, schema change, or runtime dependency beyond Composer, so the blast radius is small and reversible.
- How do I install laravel-query-enrich?
- It installs with a single composer require command under the MIT license, with no dependents to inherit. Adoption is mechanically trivial, but during a pilot you should pin the exact version in composer.json instead of a caret range and revisit after a couple of upgrade cycles. Because it likely registers builder macros or a trait, verify it does not clash with macros your application already defines.
- Which Laravel and PHP versions does laravel-query-enrich support?
- You need to check the illuminate/* and PHP require constraints in the package's composer.json before committing to it. A package pinned to older Laravel releases or PHP below 8.2 is either a non-starter or a forced-upgrade conversation for your team. The binding constraint for adoption is always version compatibility with your current Laravel minor, so confirm that first and check whether a CI test matrix exists.
- Does laravel-query-enrich work correctly with paginate() and withCount()?
- That is exactly the area to test explicitly rather than assume. Laravel re-derives selects during pagination counting, and builder internals shift across major versions, so helper packages that hook the builder can degrade quietly and return wrong counts instead of throwing. Add integration tests covering paginate(), withCount(), and toBase() on your target Laravel version before standardizing on it.
- Is laravel-query-enrich safe from SQL injection?
- Any package whose purpose is injecting SQL expressions deserves a direct audit of whether user-supplied values are parameterized or string-interpolated. This is the highest-severity finding for this kind of helper and should be read personally rather than delegated. Confirm that all interpolated values flow through bound parameters, and never pass raw request input into expression arguments unless you have verified the parameterization path yourself.
- Can I use laravel-query-enrich with the query builder and not just Eloquent?
- Yes, the package targets both Eloquent and the query builder, but it only fits where one of those is already your data-access layer. Applications using repositories that return DTOs, or hand-rolled PDO or Doctrine layers, get nothing from it. If your team already calls selectRaw and whereRaw comfortably, treat this as convenience rather than new capability.
- Does laravel-query-enrich work with MySQL, PostgreSQL, and SQLite?
- Raw SQL expressions are the least portable thing you can put in a query, so behavior depends on the dialect you run. It is fine for a single-engine shop but risky if you run MySQL in production and SQLite in tests, since dialect-specific functions may not translate. Check the package's test matrix and run your own suite against every engine you actually deploy.
- Is laravel-query-enrich production-ready and actively maintained?
- It has roughly 142 stars, a single maintainer, zero dependents, and no stated security policy, which puts it firmly in evaluate-don't-standardize territory. The absence of dependents means no transitive supply-chain risk, but also no evidence that others have stress-tested it in production. Treat it as a candidate for a scoped pilot, not a platform-level dependency, and avoid making it load-bearing.
- How is laravel-query-enrich different from selectRaw, and will it collide with my existing macros and scopes?
- The value is ergonomics: it keeps you inside Eloquent's fluent chain when appending computed columns and subquery aggregates, where you would otherwise drop to selectRaw or whereRaw. If it registers builder macros, it shares a global namespace with your own macros and scopes, so name collisions are a real if low-probability integration hazard. Audit your existing macro names before installing and prefer wrapping calls in your own abstraction.
- How hard is it to remove laravel-query-enrich if I abandon it?
- Removal cost depends entirely on containment, since the package is additive and there is no data migration involved. Wrap every call in one internal abstraction, such as a custom builder macro, a QueryEnricher service, or a small EnrichesQueries trait you own, and do not let the package API leak into controllers, resources, or domain logic. If only that single file knows the package exists, swapping it for native selectRaw later is roughly a one-day task.