Laravel Type Safe Collection Laravel Package

Product Decisions This Supports

• Domain modeling decisions: Whether to introduce typed collection classes (e.g. OrderCollection, InvoiceCollection) as first-class domain objects that enforce invariants (a collection of invoices can only ever contain invoices), versus accepting Laravel's default mixed-type Collection and relying on runtime discovery of bad data.
• Static analysis / code quality initiative scoping: This package is a proxy for the broader "how much do we invest in type safety?" roadmap question. If the org is already on Laravel 9+ with PHPStan or Psalm using @extends Collection<int, User> generics docblocks, this package's value proposition is largely already met for free — which is itself a useful signal for deprioritizing the initiative.
• Build vs. buy (build vs. adopt): A typed collection is conceptually a thin wrapper — a make() guard, a constructor type check, and @extends annotations. That is roughly 30–50 lines of in-house code. This package's build vs. buy calculation is unusually lopsided toward build, which makes it a good case study for a decision framework the team applies elsewhere.
• Legacy modernization scoping: Useful reference point when deciding whether to retrofit type safety into a pre-Laravel-8 codebase, where generic docblocks and static analysis ergonomics were weaker and a runtime-enforcing collection had clearer marginal value.
• Use cases if adopted: Preventing ->map() and ->filter() pipelines from silently degrading into mixed; making IDE autocompletion reliable across collection chains; catching bad data at the boundary (e.g. hydrating from an API payload or a loosely-typed repository query) rather than three layers downstream.

When to Consider This Package

Consider if:

• The stack is genuinely older (Laravel 6/7-era) and lacks the generic-annotation ergonomics that make static analysis viable on plain collections.
• The team has no PHPStan/Psalm coverage and is unlikely to adopt it, but wants a cheap runtime safety net at domain boundaries.
• It is confined to a non-critical internal tool where an unmaintained dependency is an acceptable, explicitly-recorded risk.
• You want a working reference implementation to copy from before writing your own — reading the source is arguably more valuable than installing it.

Look elsewhere if:

• You are on Laravel 9+ — the framework's own generics docblocks plus a static analyzer cover most of the same ground with zero dependency cost.
• Maintenance is a hard requirement. Last release was September 2020, spanning Laravel 8 through 12 without an update. A 37-star package with no recent activity has no meaningful security-patch or compatibility guarantee. Treat it as abandoned until proven otherwise.
• You need it in the request path of a high-traffic service, where a stale dependency is a compounding liability across every future Laravel upgrade.
• Your team can ship the 50-line in-house equivalent — which most Laravel teams can, in under a day.

Recommended default: write the typed collection in-house and skip the dependency. Revisit adoption only if an audit shows this package is already transitive in the tree.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk, low-strategic-value item — not a budget decision. It is a small community library that enforces type constraints on data collections. The honest framing is that the pattern is worth adopting and the package is not: the last release was 2020, it has 37 stars, and the same capability is a half-day of internal engineering with no ongoing vendor exposure. Recommendation: adopt the pattern in-house, avoid the dependency, and record the decision so it doesn't resurface.

To engineering: This package forces a single type on a Laravel Collection, catching type drift in map/filter/pluck chains at runtime and improving IDE inference. It works, and the source is a clean reference. But it has been unmaintained since September 2020, predates Laravel 9–12, and has essentially no adoption community behind it. If your analyzer already reads @extends Collection<int, Model> docblocks, this adds runtime enforcement you likely don't need. Proposed: implement a typed base collection internally following the same shape (make() guard + constructor check + generic annotation), and put the saved dependency budget toward wiring PHPStan into CI, which delivers broader and more durable value.