Query Builder Laravel Package

Technical Evaluation

• Architecture fit: Unchanged and still poor for Laravel. Nothing in the 4.0.4 notes indicates a service provider, facade, container binding, config publishing, or migration support; this remains a standalone MindyPHP-ecosystem query utility. The headline feature — JSON field support — does not close a gap, because Laravel/Eloquent already provide native JSON querying (-> path syntax, whereJsonContains, whereJsonLength) across MySQL, PostgreSQL, and SQLite. Net architectural value to a Laravel codebase is still negative: a second query abstraction layer with weaker framework integration.
• Integration feasibility: Two material changes to the prior position. First, the existence of a 4.0.4 release contradicts the earlier "last release 2018-02-05" data point; the maintenance-status claim must be re-verified against the actual release history rather than reused. Second — and more important — 4.0.4 is a patch version carrying behavior changes: the syntax for insert, update, delete, and select changed, and escaping logic changed. That is semver-breaking content in a patch release, which means upgrade safety cannot be inferred from version numbers. Any prior proof of concept is invalid and must be re-run against 4.0.4 specifically. PHP 8.1/8.2+ and current-Laravel compatibility remain unproven.
• Technical risk: High, and now elevated. The escaping change ("removed unnecessary escaping; only exceptions are escaped, analogous to dbal") is a change to the SQL serialization layer — the highest-blast-radius part of any query builder. It must be verified that values remain parameter-bound, that identifier quoting is still correct per dialect (reserved words, backticks vs. double quotes), and that no injection path opens through identifiers or JSON field names. The query-syntax change means query strings we hold are no longer portable across versions, and there is no stated migration guide. Compounding factors remain: no visible test coverage or CI, terse release notes in Russian only, 0 stars, 0 dependents, and low opportunity score.
• Key questions: Which release introduced the new select/insert/update/delete syntax, and is there a migration note or changelog? Is 4.0.4 API-compatible with earlier 4.0.x, or only with 3.x? Exactly what does the escaping change affect — values, identifiers, or both — and are values still bound as parameters? Does JSON support require minimum database versions (MySQL 5.7+/8.0, PostgreSQL jsonb), and does the generated SQL remain index-friendly/sargable? Are there tagged advisories or CVEs? Does 4.0.4 run on PHP 8.1+ under a current Laravel runtime with PDO prepared statements? Who owns the fork if upstream stalls? Can the underlying requirement be met with Illuminate\Database?
• TPM recommendation: Do not adopt for new Laravel work — the JSON addition does not change the calculus, since native Eloquent covers it with maintained, documented, framework-integrated code. For legacy MindyPHP usage, treat 4.0.4 as a breaking upgrade, not a patch: gate it behind a security review plus SQL-diff regression before bumping, and otherwise stay on the currently pinned version.

Integration Approach

• Stack fit: Low for Laravel, unchanged. Native query builder/Eloquent remains the default; JSON requirements are not a justification to adopt this package. In legacy MindyPHP services, keep the package as an isolated boundary, not a platform standard.
• Migration path: Unchanged in shape — inventory usages, map queries to Laravel's builder/Eloquent, wrap legacy calls in a repository/adapter interface, replace incrementally by domain or endpoint with contract tests and dual-run comparison. One addition: because the statement syntax changed in a patch release, the adapter must also absorb version-specific syntax differences so they never leak into domain code or shared query helpers.
• Compatibility: Expand the matrix beyond PHP and database to include package version boundaries — pre-change vs. post-change select/insert/update/delete syntax and pre-change vs. post-change escaping. Assume incompatibility until proven. Pin exact versions; do not use caret ranges on a package that ships behavior changes in patch releases. If mixed versions exist across services, test both escaping modes explicitly, since output SQL will differ.
• Sequencing: Insert the release review ahead of any upgrade: 1) confirm release history, changelog, and semver policy; 2) re-run the sandbox proof of concept against 4.0.4 on the target PHP/Laravel runtime; 3) security review of the escaping change and of JSON key/identifier handling; 4) build/extend the adapter plus a regression suite covering all four statement types and JSON fields; 5) diff generated SQL and result sets against the currently pinned version; 6) migrate or upgrade low-risk paths first under canary; 7) retire the dependency on the agreed roadmap.
• Decision: Reject for greenfield Laravel and standardize on Illuminate\Database. For legacy, upgrade to 4.0.4 only behind the adapter, with a passing SQL-diff and security gate; otherwise hold the pinned version and keep the replacement roadmap funded.

Operational Impact

• Maintenance: Still effectively team-owned, and the cost just went up. A patch release that changes query syntax and escaping means "stay current" is not a safe default — every upstream bump requires source diffing and regression. Budget for a fork-and-review-per-release model, not passive dependency updates.
• Support: No active community, no dependents, no vendor support. Release notes are three terse Russian bullets with no migration guide, so behavior must be reverse-engineered from source. An internal subject-matter expert remains mandatory; that expert's knowledge now expires with each syntax change.
• Scaling: The builder is still unlikely to be the bottleneck; database design and infrastructure dominate. The JSON feature may reduce application-side decoding work, but verify the emitted SQL is index-friendly for the target dialect and that JSON path syntax is portable across MySQL, PostgreSQL, and SQLite — otherwise scaling behavior diverges by environment.
• Failure modes: All prior modes remain (PHP breakage, dialect mismatch, missing framework integration, Composer conflicts, orphaned dependency). New and now top-of-list: silent SQL changes on patch upgrade, escaping regressions producing injection exposure or broken quoting for reserved words/identifiers, JSON path incompatibility across databases, and mixed-version behavior across services on different pins. Rollback difficulty increases because reverting a syntax change may require reverting query code as well.
• Ramp-up: High and rising. Laravel developers still gain little transferable knowledge, and now must also learn version-specific syntax variants on top of a non-standard API. Onboarding cost outweighs benefit; invest in Eloquent and Laravel query-builder expertise instead.
• Operational recommendation: Do not introduce into production Laravel systems. For existing legacy use, hold the current pin unless a JSON requirement is genuinely blocking; if 4.0.4 is required, gate on security review and SQL-diff regression, deploy behind a canary, and keep the previous pin ready as a rollback.