Laravel Any Laravel Package

Product Decisions This Supports

Dependency-governance policy — a low-stakes precedent for a real gate. This package is the ideal worked example for setting a minimum adoption bar: 38 stars, 0 dependents, a 0.25 composite score, MIT licence. It lets you socialise objective criteria — adoption signals, maintenance cadence, security-contact availability, licence fit, and overlap with native framework capability — without picking a fight over something the business actually depends on. Use it to justify a written "no unmaintained micro-packages in production" standard. The principle lands better when the example is trivially replaceable.

Build-vs-buy calibration — the cleanest test case available. The entire shipped capability is a single Collection::any(callable): bool macro that short-circuits on the first matching item: roughly six lines of first-party code. It is the reference point for "when is a dependency cheaper than writing it ourselves?" — and the answer here is never. Every later dependency request can be measured against this baseline: does it do more than six lines of work? Does it carry maintenance we would otherwise own? Does it have a future beyond the next framework upgrade?

Framework-upgrade and language-roadmap risk — PM-owned, not just engineering's. The capability is being absorbed upstream: Laravel 9+ ships native Collection::any() and PHP 8.4 adds array_any(). Adopting today creates a guaranteed cleanup ticket at the exact moment of a framework or language upgrade — dead weight against the twelve-month platform roadmap. PMs own upgrade cadence and the resulting maintenance budget, so this risk sits with us, not only with the engineers who type composer require.

Developer-experience and coding-standards ownership. If the team genuinely values JS-style any/some ergonomics in guard clauses, the decision is a one-line entry in an internal CollectionMacrosServiceProvider plus a note in the style guide — not a roadmap item. The PM owns whether the ->any() idiom is standardised across the codebase; engineering owns how it is implemented. Splitting the decision that way stops a style preference from quietly becoming an architectural dependency.

Roadmap positioning — explicitly out of scope, and useful as such. Low effort, low differentiation, zero customer-facing impact. This belongs in internal tooling, test assertions, admin utilities, and engineering onboarding. Never on a customer-facing roadmap. It is a genuinely useful teaching artefact for onboarding PMs on how little qualifies as roadmap-worthy, and on how to separate an ergonomics preference from a product decision.

Use cases to cite when the topic surfaces — each already has a first-party equivalent:

• Readable guard clauses: $invoices->any(fn ($i) => $i->isExpired()) before throwing a domain exception.
• Chained pipelines: $users->filter(fn ($u) => $u->isActive())->any(fn ($u) => $u->hasFlag('suspended')).
• Eloquent collections, which inherit the macro automatically because Eloquent\Collection extends the base collection.
• Test assertions, where assertTrue($items->any(...), 'message') gives clearer failure output than contains().
• Policies and form requests — pure boolean gates over already-loaded data, arguably the strongest legitimate fit.

The one use case that is not supported, and where PMs get burned on performance: this is in-memory only. $tenant->subscriptions()->any(...) runs SELECT * and then iterates in PHP. When the underlying question is existence, the answer is ->where(...)->exists() in SQL, not a collection macro.

A concrete pre-adoption check to put in the ticket:

php artisan tinker --execute="var_dump(method_exists(Illuminate\Support\Collection::class, 'any'));"
composer show laravel/framework | grep versions

If that prints true, the behaviour already exists with identical semantics — stop.

When to Consider This Package

Consider adoption only when all of the following hold:

• The codebase sits on a Laravel version without native any() (broadly pre-Laravel 9), so the macro is not shadowing or duplicating core behaviour. Verify first with method_exists(Illuminate\Support\Collection::class, 'any').
• The team has explicitly standardised on the ->any() idiom and prefers a published package over an internal macro for consistency or discoverability. Defensible, but weak — the ergonomics are identical either way.
• Dependency review is deliberately light because the context is a prototype, an internal tool, a timeboxed spike, or workshop material, and the cost of a stale dependency is genuinely negligible.
• The team already standardises on Nuno Maduro packages and values naming consistency; one more MIT-licensed manifest entry is an accepted cost.
• You have accepted in writing that the dependency will be removed at the next Laravel or PHP upgrade, and someone owns that ticket.

Look elsewhere — or build in-house — when:

• The application is production-critical, subject to strict supply-chain review, or tracks dependency count as a first-class engineering metric. Default position: build in-house. Six lines, full test ownership, no manifest entry, no audit surface.
• Laravel 9+ is in use. Collection::any() exists natively with identical semantics; installing the package creates two competing implementations and a silent registration-order bug on upgrade.
• PHP 8.4 is anywhere on the twelve-month roadmap. array_any() makes the dependency redundant, so adopting now guarantees a removal ticket later.
• contains($callback) already delivers the same readability and identical semantics — including short-circuiting — with zero new dependencies. This is the correct default answer for most teams.
• Expected call sites number under roughly twenty. Below that threshold the dependency never amortises its own review, audit, and upgrade cost; write the macro once and own it.
• Custom semantics are needed — key/value predicates, stricter comparison, async predicates. Extension points are effectively zero: no config, no events, no driver, no published stubs. The moment you want to change behaviour you are maintaining a fork, which is the strongest argument for starting from a vendored or internal macro instead.

Known gotchas to hand to engineering with the decision, not after it: confirm whether the macro compares with === or == before first merge and lock it with a test (loose comparison is the one real defect class — silent boolean drift no review catches); make sure the provider is registered and config:cache is rebuilt, or queue workers and early-booting Artisan commands throw BadMethodCallException; register unconditionally so Octane and long-running workers cannot boot without the macro; remember any() on an empty collection returns false, which is not the negation of every(); and if you do ship it, note it in the ADR, run composer audit in CI, and file the removal ticket the day you install it.

How to Pitch It (Stakeholders)

For executives — one line: this is a six-line convenience macro that duplicates capability Laravel now ships natively, so our recommendation is to standardise the idiom internally and not take the dependency; the decision costs nothing today and saves a cleanup ticket at the next platform upgrade.

For engineering — the substance: on Laravel 9+ this is pure overhead — Collection::any() already exists with identical short-circuiting semantics, and installing the package gives two competing implementations resolved by provider registration order. On older versions the same behaviour is six lines in one CollectionMacrosServiceProvider, which we control, test, and can retire in a single commit. We keep the ergonomics we like ($invoices->any(fn ($i) => $i->isExpired()) in guard clauses, pipelines, Eloquent collections, policies, and test assertions), and we keep the manifest clean. We also get to choose our own comparison semantics explicitly rather than inheriting whatever == versus === the package happens to use.

Framing that travels well: this package is our worked example for dependency hygiene — low adoption signals (38 stars, 0 dependents), a single capability overlapping native framework and language features, and zero extension points. Treating it as the floor of the adoption bar sets a defensible precedent that costs the business nothing to enforce, and gives every future "can we just add this package?" conversation a shared reference point. It is an internal tooling and onboarding decision, not a product decision, and it should never appear on a customer-facing roadmap.