Flexible Where Between Laravel Package

Technical Evaluation

Architecture fit. primitive/flexible-where-between is a single-purpose Eloquent query-scope package: it wraps Laravel's native whereBetween with more forgiving inputs (null bounds, mixed date/string types, open-ended ranges). Architecturally it is a thin sugar layer over the query builder — no service container bindings of consequence, no persistence, no background work, no external I/O. That makes it a near-zero-footprint fit for any existing Laravel monolith or API service. It does not impose patterns, so it neither helps nor hurts our architecture; it only reduces boilerplate in controllers/repositories that filter on ranges (reporting windows, date pickers, price bands).

Integration feasibility. MIT-licensed and Composer-installable, so legal and mechanical friction is minimal. The blocker is version currency: the last release is November 2020, which places it in the Laravel 7/8 era. Modern Laravel (10/11) requires Illuminate 10/11 and PHP 8.1/8.2, and this package's composer.json constraints almost certainly will not resolve. Integration is therefore trivial on legacy Laravel 6–8 applications and effectively blocked-by-default on current ones without a fork or a constraint override — and overriding constraints on a query-semantics package is a bad trade.

Technical risk. Low security risk (no network, auth, filesystem, or deserialization surface), high maturity and abandonment risk. Fifteen stars, zero dependents, and four years without a release is a strong signal of a single-maintainer package that is no longer watched. The real hazard is not compromise but semantic rot: range logic has subtle contracts (inclusive vs. exclusive endpoints, null-bound behavior, Carbon vs. string vs. DateTimeImmutable coercion, timezone handling on date-only columns). If those semantics are undocumented or untested, we inherit ambiguity in exactly the place bugs are expensive — financial periods, reporting cutoffs, and pagination consistency.

Key questions for the maintainer/spike.

1. What happens when both bounds are null — does it emit no WHERE clause (full scan) or an always-false clause? This single behavior determines whether a malformed filter can degrade a production query.
2. Are endpoints inclusive on both sides, and is that consistent with our existing whereBetween usage?
3. Does it ever wrap the column in a function (e.g., DATE()) or introduce OR predicates that defeat our indexes?
4. Is the logic covered by a test suite we can execute against our PHP version?
5. How small is the implementation — can it be vendored outright rather than depended upon?

Integration Approach

Stack fit. Native Laravel/Eloquent; no infrastructure, queue, cache, or config footprint. It slots into the repository/query-object layer alongside existing scopes and composes with pagination, when() conditionals, and eager loading. Nothing about our deployment topology changes.

Migration path. The recommended path is vendor, don't depend. Given the package's size and staleness, the pragmatic move is to lift the scope/trait (or reimplement the ~dozens of lines it represents) into our own application code with our own tests. This eliminates the abandoned-dependency line item, resolves the Laravel 10/11 constraint problem instantly, and lets us own the semantics. If a team insists on the dependency, pin the exact version and mirror it through a private Satis/Composer repository so builds are reproducible after Packagist or GitHub state changes.

Compatibility. Verify composer.json require constraints against our Laravel/PHP matrix before any spike; expect a hard failure on Illuminate 10+. On PHP 8.1+, watch for deprecation notices from 2020-era code. If we fork, we own forward-compatibility and should add a matrix test against our supported Laravel versions.

Sequencing.

1. Semantics spike (1–2 days): write failing tests for the behaviors we actually need — open-ended ranges, null handling, date boundaries, timezone behavior — against the current package on a legacy branch if available.
2. Decide vendor vs. depend based on the spike outcome; default to vendor.
3. Extract and harden: move the trait into app code, port the tests, add index-usage assertions (EXPLAIN) for the generated SQL.
4. Codify the contract in our own test suite so future refactors can't silently change range semantics.
5. Adopt incrementally in one reporting/filter surface first, then broaden only after a release cycle.

Operational Impact

Maintenance. Runtime maintenance is negligible; dependency hygiene cost is not. A stale, zero-dependent package will surface in SCA/composer audit and Laravel upgrade checklists indefinitely, and each appearance costs review time. Vendoring converts that recurring tax into a one-time cost.

Support. Effectively none. No vendor, no active maintainer, no community mass to attract third-party fixes. Any defect becomes an internal ticket with an internal owner. Budget for that explicitly — do not let it land on a team that assumes "it's just a Composer package."

Scaling. The package contributes nothing to load characteristics; performance is entirely the generated SQL. The scaling concern is query plan risk: if the flexibility is implemented with column-wrapping functions, OR chains, or omitted predicates when bounds are null, we get non-sargable scans on large tables. Validate against production-sized data and confirm index usage before broad adoption. Also confirm it plays well with chunkById/cursor pagination, since range filters frequently pair with batch jobs.

Failure modes.

• Build failure on framework upgrade — highest probability, low severity, but blocks the whole upgrade until someone notices.
• Silent full-table scan when a caller passes null/null and the scope drops the predicate entirely — highest severity; guard at the call site.
• Off-by-one / timezone range errors where a date-only column is compared against an inclusive timestamp, producing boundary-day omissions in reports.
• Fork drift if we vendor and then diverge without tests, reintroducing the ambiguity we were trying to escape.

Ramp-up. Low for any Laravel developer — on the order of half an hour to read the README and the source. The ramp-up cost that matters is organizational, not technical: establishing ownership and a decision (vendor vs. depend) so the package doesn't linger as an unowned transitive dependency. Given the maturity signals, my recommendation is to treat this as a code snippet to internalize, not a dependency to adopt, and to fund a short spike only if a team is currently blocked on range-filter boilerplate.