Laravel Eloquent Where Not Laravel Package

Technical Evaluation

Architecture fit: Low strategic fit, unchanged. Release 1.2.0 adds only “Support for Laravel 9”; it does not alter the package’s role as a narrow Eloquent query-builder extension for inverting scopes or constraints. It remains suitable only for a legacy Laravel 9 codebase with many scope-inversion call sites and no acceptable native alternative. The release is a compatibility patch, not evidence of a broader architectural or governance commitment.

Integration feasibility: Technically easy on Laravel 9. Composer installation, Laravel auto-discovery, a small API surface, and MIT licensing still make a constrained pilot straightforward. Release 1.2.0 removes one compatibility concern for Laravel 9 targets, but governance feasibility remains low: a single one-line compatibility release does not establish active maintenance, security response, or a roadmap. Laravel 10/11 and newer PHP versions remain unproven.

Technical risk: Still high relative to value. The new release reduces Laravel 9 compatibility risk, but it does not address the core risks: no demonstrated security or bug-fix maintenance, abandoned-dependency scanner exposure, unverified test coverage against modern Laravel, and subtle negation semantics around orWhere, nested constraint groups, relationship constraints, and SQL NULL three-valued logic. Treat Laravel 9 support as a narrow compatibility signal, not production evidence.

Key questions: Does 1.2.0 change composer.json constraints only for Laravel 9, or also for supported PHP versions? Which Laravel 9 minor and PHP version must be supported? Are there tests proving the release against Laravel 9? Does native whereNot/orWhereNot or closure-based negation cover the use cases? How many call sites require scope inversion? Can the implementation be vendored or rewritten locally? Does the package correctly negate orWhere, nested groups, relationship constraints, and NULL cases? Who owns maintenance if adopted? Is 1.2.0 an isolated compatibility patch or the start of renewed maintenance? Does it register global builder macros with side effects?

TPM recommendation: Do not adopt as a long-term runtime dependency. Release 1.2.0 makes a Laravel 9-only pilot more feasible, but it does not change the strategic recommendation. Prefer native Laravel negation patterns or a local query macro. If the package’s exact behavior is required, vendor the small MIT-licensed logic into the application with tests and explicit ownership rather than depending on the upstream repository.

Integration Approach

Stack fit: Improved for Laravel 9 only. Release 1.2.0 explicitly claims Laravel 9 support, so verify its composer.json constraints against the target Laravel 9 minor and PHP version before any pilot. Treat Laravel 10/11 and PHP 8.2/8.3 compatibility as unproven until contract tests pass.

Migration path: Inventory existing scope-inversion needs, then prefer native Laravel negation patterns or a local query macro. If the target is Laravel 9 and the package’s exact behavior is required, a time-boxed pilot is reasonable. Do not assume 1.2.0 makes the package a sustained dependency; copy the implementation into an application support class if long-term use is needed. Preserve MIT attribution if vendoring.

Compatibility: MIT licensing permits forking or vendoring. The 1.2.0 release lowers the Laravel 9 compatibility barrier, but zero dependents still means no production evidence. Pin the dependency for any pilot, run the package tests against the target Laravel 9 version, and add application-level tests for negation semantics.

Sequencing: 1) Confirm 1.2.0 constraints and changelog scope for Laravel 9 and PHP. 2) Discover and classify required inversion cases. 3) Spike a native/local implementation against those cases. 4) Decide reject, vendor, or fork; allow a Laravel 9-only pilot only if native/local options fail. 5) Add regression tests for orWhere, nested groups, relationships, and NULL behavior. 6) Roll out narrowly with a documented replacement or deprecation date.

Operational Impact

Maintenance: If adopted, maintenance becomes internal immediately. Release 1.2.0 is a small compatibility update, but the codebase must still be tracked against Laravel query-builder changes. Ongoing maintenance cost likely exceeds the feature value.

Support: No meaningful upstream support signal beyond the Laravel 9 compatibility note. Community usage remains negligible, so incident resolution depends on internal engineers reading the source. Security and long-term compatibility patches should not be assumed.

Scaling: Runtime overhead remains negligible; the package only influences query construction. The real scaling concern is query complexity: broad use of inverted constraints can produce harder-to-review SQL and increase the need for query-plan validation.

Failure modes: Incorrect negation of complex constraints, NULL semantics, orWhere precedence bugs, silent behavior changes after Laravel upgrades, Composer conflicts, and policy violations from abandoned dependencies. Release 1.2.0 does not address these failure modes. They are likely to appear as incorrect result sets rather than runtime exceptions, making them costly to detect.

Ramp-up: Low for engineers to learn the API; higher for the organization to own effectively unmaintained code. Document the negation semantics, require tests for every adopted pattern, and keep usage narrow until a native replacement is in place.