Foundation Laravel Package

Product Decisions This Supports

• Runtime upgrade planning (immediate): 2.2.0 drops PHP 8.4 support. Any roadmap item that assumes PHP 8.4 runtimes in the next 1–2 cycles is now in tension with this dependency. Decide explicitly: stay on 2.1.0 (keeps 8.4), pin the platform to ≤8.3, or vendor/fork the package.
• Build vs buy for domain primitives: this is a framework-agnostic functional foundation library (immutable collections, option/either-style types) rather than a Laravel-native package. The buy decision is cheap on license cost but carries an adoption cost — the team writes in a functional style rather than Illuminate\Support\Collection.
• Architecture bet: whether domain/service layers should express failure as return values instead of exceptions. Approving this package signals a preference for explicit, typed error handling; rejecting it signals staying with Laravel idioms.
• Dependency-risk posture: a maintainer publishing a minor-version platform-support regression is a signal about release discipline. That informs whether this sits in "trusted default" or "pin and review on every bump" on the dependency register.
• Scoping use cases: highest value in domain-heavy, rules-driven services where immutability and exhaustive matching prevent whole classes of bugs; low value in CRUD, form-heavy, or admin-panel work where Laravel's built-ins already cover the need.

When to Consider This Package

Adopt when:

• The domain layer already avoids Laravel framework coupling, or you are deliberately keeping it out of business logic.
• The team is comfortable with functional idioms and will use immutable collections and option/either types consistently rather than sporadically.
• Your CI matrix and production runtimes run on PHP 8.2/8.3 — the versions that remain supported after 2.2.0. If you are on 8.4, pin 2.1.0 behind an explicit constraint and track the issue.
• You want a small, single-maintainer dependency with a narrow surface area rather than a broad framework bundle.

Look elsewhere when:

• You need first-class Laravel integration — service providers, facades, config publishing, Eloquent-friendly helpers. Nothing in this release indicates Laravel-specific bindings; assume you own the wiring.
• You need vendor SLAs, formal LTS windows, or a large contributor base. Single-maintainer projects with platform-support churn are a poor fit for regulated or long-horizon commitments.
• The team will not sustain the functional style. Partial adoption produces two competing collection APIs in one codebase — a net negative versus just using what ships with the framework.
• PHP 8.4 is a hard requirement this quarter and you cannot pin or fork.

How to Pitch It (Stakeholders)

Executives: This is a low-cost, no-license internal code-quality decision, not a customer-facing feature. The one thing that needs a decision now is the platform constraint: release 2.2.0 removes PHP 8.4 support, so adopting or upgrading it locks us to PHP 8.3 or below until the maintainer restores it. Recommendation: do not adopt as a default; approve it only for a bounded, domain-heavy service where the team has the right skills, and pin the version explicitly so a routine composer update cannot silently narrow our runtime options.

Engineering: Framework-agnostic functional foundation library — immutable collections and option/either types, used in domain layers rather than in controllers or Eloquent models. 2.2.0 is effectively a breaking platform change: PHP 8.4 is dropped from the support matrix, so verify our runtime and CI matrix against Composer constraints before bumping, and set an explicit version pin plus a review-on-bump policy. Budget for a light internal wrapper or coding-convention note so the codebase converges on one collection abstraction instead of two.