Laravel Eloquent Where Not Laravel Package

Product Decisions This Supports

• Build vs. buy (here: build vs. copy). The package solves exactly one narrow ergonomic problem: inverting an existing Eloquent scope or query constraint without re-deriving its logic in negative form. Release 1.2.0 (Laravel 9 support) does not broaden that scope — it only moves the compatibility ceiling. Since it is MIT-licensed, archived, and small, the realistic decision remains "vendor ~a trait into our codebase," which converts a supply-chain question into a copy-paste one.
• Reducing duplication in query logic. The strongest product argument is defect prevention: when a positive scope (active(), published(), withinBudget()) and its negation live in two places, they drift. Any whereNot(fn ($q) => $q->scope()) pattern makes the negation derive from the source of truth, which shrinks the surface area for "the filter says one thing, the exclusion says another" bugs in admin panels, reports, and export jobs.
• Feature velocity on filter/exclusion UX. Products with paired include/exclude affordances — segmentation builders, marketing audience filters, audit/exception views ("show me everyone not in the beta cohort") — get a reusable primitive instead of hand-written negatives per feature.
• Roadmap signal on "inverse" requirements. If the roadmap repeatedly produces tickets phrased as "all X except those matching Y," that is a signal to standardize a negation convention at the query layer rather than let each squad improvise.
• Architecture decision: framework version floor — now resolved. 1.2.0's sole change is Laravel 9 compatibility, and Laravel 9 is also the baseline at which native whereNot/orWhereNot became available. The package's compatibility update therefore closes the gap it was meant to fill: any app new enough to run 1.2.0 is new enough to use the framework primitive. Treat this as an input to an "adopt the native convention / drop the polyfill" roadmap item, not as a dependency decision.
• Not a decision this supports: anything involving performance, security posture, observability, or multi-tenant correctness. It is syntactic sugar over the query builder; it changes how conditions are expressed, not how they execute.

When to Consider This Package

Consider the concept (strongly) when:

• You have a mature set of Eloquent local scopes that are consumed in both positive and negative forms, and duplication is already causing drift.
• Your negation need is specifically scope inversion, which native whereNot does not fully cover ergonomically (native support targets grouped constraints, not named-scope inversion).
• You can lift the trait directly into app/Support under the MIT license with attribution — this eliminates the archived-dependency risk entirely and is the only form in which 1.2.0 is relevant to us.
• Your team accepts the semantics of SQL negation and understands the NULL behavior (NOT (col = 'x') is not col != 'x' when col is NULL) plus the OR-precedence trap when a scope mixes where and orWhere.

Look elsewhere (or write your own ten lines) when:

• You are on Laravel 9 or newer — which, post-1.2.0, is the only population that can install this package. Audit native whereNot/orWhereNot first; you may already own 70–100% of this. The release narrows the package's addressable audience to people who already have the alternative.
• Any scope you intend to invert contains orWhere, joins, whereHas with nested or, or aggregates. Inversion of these is not mechanically safe, and a "clever" one-liner here is a correctness incident waiting to happen.
• You require vendor support, a security response process, or a compatibility guarantee across future Laravel majors. The package is archived and has 28 stars and 0 dependents. 1.2.0 adding Laravel 9 is a maintenance courtesy, not a resumption of maintenance — Laravel 9 is itself past end of security support, so the package now tops out below the current framework line. Treat it as unmaintained sample code, never as infrastructure.
• Your dependency policy forbids abandoned packages, or your SBOM/audit tooling flags archived repos. Do not fight that policy for a convenience method.
• The negation is used in access-control, billing, or compliance queries. In those paths, an explicit, reviewed negative scope beats a generic inversion, because the reviewer needs to see the predicate, not infer it.

Adoption criteria (all should hold): MIT attribution retained if vendored · no archived package added to composer.json (1.2.0 does not change this) · inversion limited to simple AND-only scopes · unit tests asserting positive and negative result sets are complementary on fixtures that include NULLs · a documented escape hatch back to explicit scopes.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small open-source utility that lets our code express "everything except what this existing filter matches" without rewriting the filter backwards. The business value is fewer reporting and segmentation bugs caused by a filter and its exclusion drifting apart, plus slightly faster delivery on include/exclude features. It is free (MIT), tiny, and unmaintained; the new 1.2.0 release only adds Laravel 9 support — a version that already ships the framework equivalent — so our recommendation is unchanged: copy the relevant snippet into our own codebase rather than take on a dependency. Cost is a few hours of an engineer's time; risk is near zero; upside is modest and localized.

To engineering (the honest version): Protonemedia's laravel-eloquent-where-not inverts an Eloquent scope or query constraint so negation derives from a single source of truth. 1.2.0 adds Laravel 9 support and nothing else — no API changes, no fixes, no deprecations — so it does not alter the verdict: do not add it to composer.json. It remains archived, has 28 stars and no dependents, and its compatibility ceiling now sits at a version that already provides native whereNot. Instead: (1) verify whether native whereNot covers the case; (2) if the gap is specifically scope inversion, vendor the trait into app/Support with MIT attribution and a short docblock; (3) restrict its use to AND-only scopes and add complementary-set tests with NULL fixtures; (4) for scopes containing orWhere, joins, or whereHas, write an explicit negative scope and get it reviewed. Ship it behind a convention, not a dependency.

To security/compliance, if asked: no data leaves the application, no runtime service dependency, no network calls; the only artifacts are source lines copied under a permissive license. The 1.2.0 release changes only a Composer version constraint, so there are no new transitive dependencies to review. The residual risk is logical, not operational — hence the guardrails on OR and NULL semantics rather than on provenance.