Foundation Laravel Package

Technical Evaluation

Architecture fit. innmind/foundation is not a Laravel package. It is the low-level primitive layer of the Innmind ecosystem — immutable collections, Maybe/Either monads, value-type helpers — and it is deliberately framework-agnostic with no service providers, facades, config files, or package discovery. Technically it installs cleanly into a Laravel application via Composer. Architecturally it is a foreign body: Laravel's idioms (mutable Collection, Eloquent hydration, facades, global helpers) sit in direct opposition to Innmind's strict-typing and total-immutability philosophy. Fit is therefore "coexists, does not integrate."

Integration feasibility. Low technical friction, high cultural friction. composer require innmind/foundation will work; no Laravel bootstrapping is required because there is nothing to bootstrap. The real cost is that every boundary between Laravel-land and Innmind-land needs a hand-written adapter, and there is no existing Laravel bridge, recipe, or community precedent to copy.

Technical risk. Release 2.2.0 drops PHP 8.4 support. This is published as a patch-level-minor bump (2.1.0 → 2.2.0) but it is functionally a platform-support regression. Two risks compound:

• If 8.4 is removed from the CI matrix and a php constraint is tightened, any team on PHP 8.4 — the default for new Laravel 11/12 builds — hits a hard Composer resolution failure. This effectively caps the host platform.
• If it means only "no longer tested on 8.4," the package will still install but is unsupported on the runtime the rest of the stack is standardising on. That is a silent-risk posture rather than a loud one, which is worse for a TPM to defend.

Either way, a package that removes support for a current PHP release is signalling constrained maintenance bandwidth. That is the dominant risk here, not the code itself.

Key questions.

1. What exactly changed in composer.json — is php: 8.4 excluded by constraint, or only removed from CI?
2. Why was 8.4 dropped (upstream dependency incompatibility, maintainer bandwidth, deliberate policy)?
3. Is 8.4 support planned to return, and on what timeline?
4. Which PHP versions are now the supported floor and ceiling, and does that intersect with our target Laravel version's own constraint?
5. Is the maintainer the sole author, and what is the release cadence and issue-response history?
6. Does the team actually need Innmind primitives, or is this an architecture preference looking for a justification?

Integration Approach

Stack fit. Composer-native, PSR-4 autoloaded, zero framework coupling — so it slots in without touching config/app.php, service container, or middleware. It is usable inside jobs, console commands, domain services, and queue workers. It is not a substitute for Laravel's Collection, validation, or Eloquent; treat it as a domain-layer utility library, not infrastructure.

Migration path. Nothing to migrate — there is no prior adoption and no prior assessment. If we adopt, do it greenfield in one bounded context:

1. Pin the exact version (2.2.0) and commit the lock file.
2. Verify the resolved php constraint against our runtime before anything else. If a PHP 8.4 upgrade is on the roadmap, this package is now a blocker and that must be surfaced immediately.
3. Introduce Innmind types behind an anti-corruption layer: toDomain() / toEloquent() adapters so Eloquent models and Collection never appear inside Innmind-typed code and vice versa.
4. Keep the dependency out of controllers, Blade, and anything a mid-level developer touches casually.

Compatibility. The PHP version constraint is now the gating factor and it must be reconciled against the Laravel version's own PHP floor and ceiling. Secondary checks: static analysis (Psalm/PHPStan) configuration, since Innmind leans heavily on generics and template annotations that will not type-check cleanly against untyped Laravel code without suppression; and whether any transitive Innmind dependency carries its own PHP constraint that is stricter still.

Sequencing. (a) Composer constraint audit → (b) PHP-version decision → (c) single-module pilot behind adapters → (d) team review of the pilot → (e) expand or abandon. Do not start at (c). Because the release is a platform-support reduction, steps (a) and (b) are the ones that can invalidate the whole plan, and they are cheap to run.

Operational Impact

Maintenance. Single-maintainer ecosystem with a narrow contributor base; the 2.2.0 changelog shows one PR from one author. Bus factor is 1. The release itself is minimal — one change, no features, no deprecations of API surface — which is reassuring for stability but also indicates a low-activity project. Dependency updates will be infrequent and driven by the maintainer's own needs, not ours.

Support. No commercial backing, no Laravel-community overlap, no Stack Overflow corpus. Support is GitHub issues on the maintainer's schedule. Internal capability must be self-sufficient; we cannot hire for this.

Scaling. Runtime cost of immutable collections is acceptable and not the constraint. The scaling constraint is cognitive: every engineer who touches the code must learn Maybe/Either and persistent data structures, and every Laravel developer who does not will produce boundary code that defeats the purpose. Cost scales with headcount, not with traffic.

Failure modes.

• Resolution failure on PHP upgrade — highest probability, highest blast radius. A routine platform bump becomes a fork-or-remove decision.
• Abandonment — no releases for a year leaves us pinned and eventually in conflict with security patches elsewhere.
• Boundary erosion — Eloquent models leak into Innmind-typed code, static analysis is suppressed, and the discipline that justified the dependency quietly disappears.
• Silent unsupported runtime — if 8.4 was only dropped from CI, we may run on an untested PHP version without knowing.
• Fork divergence — patching the PHP constraint locally creates a maintenance liability with no upstream path.

Ramp-up. Non-trivial for a Laravel-centric team: budget roughly two to three weeks of one senior engineer's time to reach productive fluency in the Innmind idioms, plus ongoing review overhead in the first quarter. The PHP 8.4 question should be settled before that investment is made, because a "no" there makes the ramp-up spend wasted. Recommendation: treat 2.2.0 as a major-version event for planning purposes, hold adoption until the 8.4 stance is confirmed in writing, and if confirmed as a permanent ceiling, do not adopt.