Query Builder Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for SQL abstraction. The package remains a small, MIT-licensed query builder extracted from the MindyPHP framework, and its practical value is still primarily as a reference implementation rather than a dependency. The 4.0.4 release adds evidence for a "borrow the pattern, don't take the dependency" decision: the project is willing to make breaking changes to core query syntax, which is exactly the kind of churn we would inherit if we adopted it.
• Query-layer standardization. Reinforces the decision to keep illuminate/database (Eloquent/Query Builder) as the single sanctioned query layer in Laravel-based products and to reject parallel query abstractions that fragment conventions, testing, and security review. A release that rewrites insert/update/delete/select syntax and changes escaping semantics is a concrete illustration of the maintenance tax a second query layer imposes.
• Architecture for edge/non-Laravel services. Still relevant when scoping small PHP CLI tools, cron scripts, or internal admin utilities that should not boot a full framework. JSON field support in 4.0.4 marginally widens the fit for services persisting document-style columns, but the breakage risk means the raw-PDO alternative must be evaluated honestly rather than assumed worse.
• Vendor/package due diligence criteria. The release is a useful case study for adoption gates: a major-version bump with breaking syntax changes, an escaping/security-semantics change, and no visible disclosure process in the public signals. Codifying gates around "who owns the upgrade path" remains a product decision in itself.
• Explicit non-decision. Signals remain thin (0 stars, 0 dependents, opportunity score ~24.6/100). One release does not constitute a cadence. This package should still not anchor roadmap investment, platform bets, or a migration plan — treat it as a low-cost evaluation input only.

When to Consider This Package

Consider it when:

• You need a reading reference for how a compact query builder is structured — 4.0.4 is arguably a better reference than 3.x because it documents an explicit escaping policy modelled on doctrine/dbal semantics and shows how JSON column handling is layered on.
• You are prototyping an internal, non-customer-facing PHP script/CLI and want zero framework overhead, and you can pin to a known version.
• License hygiene is the primary constraint (MIT is permissive and low-friction).
• The work is a timeboxed spike, not a committed dependency.

Look elsewhere when:

• You are in a Laravel application — use the built-in illuminate/database query builder and Eloquent. This package is redundant.
• You need maintained, security-reviewed alternatives: illuminate/database standalone, doctrine/dbal, cycle/orm, aura/sqlquery, or medoo.
• Your runtime targets PHP 8.x — the lineage is pre-PHP-8 era and there is no public evidence of a CI/test matrix against current versions.
• Anything handles PII, payments, auth, or customer-facing traffic: no visible security disclosure process, no dependents, and effectively a bus factor of one. Escaping semantics changed in this release, which makes the absence of a disclosure channel more consequential, not less.
• You require SLAs, LTS guarantees, a vendor relationship, or a predictable upgrade path.

Red flags to weigh: ~7 years of dormancy followed by a major-version release that breaks the insert/update/delete/select query syntax; a change to escaping behaviour that alters injection-safety assumptions; no community footprint, no dependent packages, and no public evidence of a test matrix. A single release after years of silence is not a cadence — it is an unannounced ownership event.

How to Pitch It (Stakeholders)

To executives: This remains a small, permissively licensed utility with negligible strategic value (opportunity score ~24.6/100) and no ecosystem traction. The new 4.0.4 release does not change that: it is a breaking change to core query syntax plus a change to escaping behaviour, shipped without any public signal of ongoing support, test coverage, or a security disclosure process. Recommendation stands: do not adopt as a dependency. The low acquisition cost is still offset by unmaintained-code risk — and now also by upgrade risk.

To engineering: Cheap to read, expensive to own — and 4.0.4 makes ownership more expensive. The query syntax for select/insert/update/delete changed, so any code we wrote against 3.x would need rewriting; escaping is now exception-based, modelled on doctrine/dbal, which shifts the burden of correctness onto callers in ways that need explicit review. JSON field support is a genuinely useful capability, but it does not offset a bus factor of one and an unknown PHP 8.x test story. A one-to-two day spike to mine patterns is defensible if we have a real non-Laravel lightweight-service need; committing to composer.json is not.

Recommendation: Reject as a production dependency. Standardize on Laravel's native query builder. If we spike it as a design reference, pin an exact version and read 4.0.4 as the current state of the API, not 3.x. Revisit only if a concrete non-Laravel service materialises — at which point evaluate maintained alternatives (doctrine/dbal, aura/sqlquery, medoo) first and this package solely as a design reference. Decision asked of stakeholders: approve a timeboxed evaluation (≤2 days) or close the ticket.