Eloquent Filters Laravel Package

Product Decisions This Supports

• Build vs. buy / adopt vs. defer: The only hard datapoint available is release 1.0.1, a one-line packaging fix. That is enough to judge installation ergonomics, not enough to judge functional fit. Treat this assessment as a gate on "is it safe to trial," not "should we standardize on it."
• Onboarding cost / time-to-first-value: 1.0.1 adds the missing Laravel service provider to composer.json, which means the package is now discoverable via Laravel's package auto-discovery. composer require should register the provider without hand-editing config/app.php. If onboarding docs still instruct manual provider registration, they are now stale — that's a docs ticket, and it affects the friction number you'd quote when comparing this against an in-house build.
• Roadmap sequencing: The package is at 1.0.x with at least one packaging defect shipped in 1.0.0. That is a normal, low-severity maturity signal — it argues for piloting on an internal or non-revenue-path surface first, not for a hard no.
• Dependency and upgrade policy: 1.0.1 is a patch with no API surface change, so it is safe to pin as ^1.0 and take automatically. No migration work, no deprecation shims to plan around.
• Ecosystem fit: Auto-discovery requires Laravel 5.5+. If any target application sits below that, the "zero-config install" benefit disappears and manual provider registration remains in scope — a real cost if you operate a fleet of mixed-version apps.

When to Consider This Package

Consider it when:

• You are on a Laravel version with package auto-discovery and want a drop-in composer require with no manual service provider wiring — 1.0.1 is the first release where that promise actually holds.
• The capability sits on a non-critical path, or you have a plausible fallback, and you are comfortable being an early adopter of a 1.0.x package.
• You can absorb a patch-level dependency bump with no code changes on your side.

Look elsewhere (or build in-house) when:

• The capability is core to your product and you need vendor stability, a support commitment, or an LTS-style guarantee that a 1.0.x package has not yet demonstrated.
• You require documented test coverage, a changelog history, or a maintainer responsiveness track record — a single packaging fix is not evidence of any of these.
• You run Laravel versions predating auto-discovery, where the headline benefit of this release does not apply.
• You cannot verify what the package actually does. Two release notes and no functional documentation is not a sufficient basis for an adoption decision; the pilot in the section above exists precisely to close that gap.

How to Pitch It (Stakeholders)

For executives: Low-stakes, low-signal release. 1.0.1 is a packaging correction — the package now installs cleanly into a standard Laravel application without manual configuration. No new functionality, no breaking changes, no security implications, no cost. Recommendation is unchanged: worth a scoped trial on one internal surface, not a committed platform bet. Do not read this release as evidence of maturity; it is evidence that 1.0.0 shipped with an incomplete manifest.

For engineering: 1.0.1 adds the service provider to composer.json, enabling Laravel package auto-discovery. Expect composer update to pull it in with no code changes. Please confirm with php artisan package:discover after upgrading, and remove any manual provider registration from config/app.php and from your setup docs — leaving both in place risks a double registration. If you pinned 1.0.0 explicitly, bump the constraint. No deprecations, no migrations, no config changes.

Caveat to carry forward: this assessment rests on a single patch release note. Before the pilot ships, get the README, the test suite status, and the maintainer's release cadence on record — those, not 1.0.1, will determine whether this becomes a standing dependency.