Laravel Bento Laravel Package

Technical Evaluation

Architecture fit. eXolnet/laravel-bento is a thin Laravel integration layer over the Bento tracking/email API — a service provider, facade/manager binding, publishable config, and event/queue hooks. It does not impose architectural opinions beyond the container and queue, so it slots into a standard Laravel app with low coupling. That remains true in v2.9.0; nothing about the package's shape changed.

Integration feasibility. v2.9.0 is a platform-floor release, not a feature release. Two constraints move simultaneously:

• Laravel 11 is explicitly dropped. Effective support is now Laravel 12+ (the release note states the removal but not the resulting lower bound — this must be confirmed against composer.json).
• PHP support is "adjusted to 8.4," which in context reads as a minimum of PHP 8.4, not merely a maximum tested version.

Net effect: any application on Laravel 11, or on PHP 8.2/8.3, cannot consume this release without first doing a framework and runtime upgrade. Feasibility is therefore a function of the host application's baseline, not of the package's complexity.

Technical risk.

• Semver risk (highest). Dropping a framework major and raising the PHP floor is a breaking change shipped in a minor version bump (2.8.0 → 2.9.0). A ^2.8 constraint will silently resolve to a release the application cannot run. This is the single most important finding.
• Runtime risk. PHP 8.4 introduces deprecations (notably implicit-nullable parameters) that commonly surface as noise or failures in older dependency trees. The floor raise may be forced by a transitive dependency rather than chosen — unknown.
• Support-window risk. Raising the floor this aggressively on a low-traffic community package suggests the maintainer intends to track only current Laravel. Older-major consumers may be left without a patched branch.
• Scope risk. The changelog is one line and one PR. There is no stated API surface change, but "no stated change" is not "no change" — the diff needs reading.

Key questions.

1. What is the exact composer.json support matrix after v2.9.0 — laravel/framework and php constraints, and which majors are listed?
2. Will a 2.8.x branch receive security/bug fixes, and for how long?
3. What forced the PHP 8.4 floor — the package itself, or a bumped transitive dependency (Bento SDK, HTTP client)?
4. Aside from the constraint edits, does PR #58 alter any public API, config keys, or event payloads?
5. Is this a deliberate policy shift (track-current-only) or a one-off? That determines whether future minors are equally unsafe to auto-adopt.

Integration Approach

Stack fit. The package is only adoptable on Laravel 12 + PHP 8.4. On Laravel 11 or PHP ≤8.3 it is unusable at this version. For greenfield work on a current stack it is a straightforward, low-friction dependency; for anything with an established baseline it is a gated upgrade.

Migration path. There is no in-place path — this is a forced sequence, and the order matters:

1. Upgrade PHP to 8.4 and remediate deprecations across the whole dependency tree.
2. Upgrade the framework to Laravel 12, resolving any packages that pin below it.
3. Only then bump laravel-bento to ^2.9.

Attempting step 3 first will produce an unsatisfiable constraint and is the most likely failure mode in practice.

Compatibility. Before committing, audit the lockfile for anything pinning laravel/framework to 11 or php below 8.4 — those are hard blockers independent of this package. Also verify the Bento SDK version transitively required has not itself moved.

Sequencing and guardrails.

• Do not widen the constraint to ^2.9 on an app still on Laravel 11; pin explicitly to 2.8.* in the interim so Composer cannot resolve into an unrunnable release.
• Run the upgrade in a dev environment first, with composer why-not used to surface blockers.
• Re-publish/merge the config file rather than overwriting it; confirm no config keys were renamed.
• Exercise the queue path end-to-end (dispatch a tracked event, confirm delivery) before promoting — this is where silent breakage hides.
• Roll out behind the framework upgrade, not as an independent change, so failures are attributable.

Operational Impact

Maintenance. Small-vendor, low-ceremony package with an infrequent release cadence and a single-line changelog. The maintenance burden on the consumer is not the package code — it is the platform treadmill: the package now dictates the application's minimum Laravel and PHP versions, so every framework upgrade becomes a dependency upgrade and vice versa. Budget for this in upgrade planning rather than treating it as a passive dependency.

Support. No announced LTS or backport branch. Assume fixes land only on the newest constraint set. If the organisation must remain on Laravel 11 for compliance or vendor reasons, this package effectively becomes unsupported — that is a decision to escalate, not absorb.

Scaling. The package is a thin client; throughput is bounded by Bento's API rate limits and by queue worker capacity, not by package internals. Scaling levers are queue concurrency, batching, and backoff policy — all application-side. No scaling concern introduced by v2.9.0.

Failure modes to instrument.

• Silent event loss — queue job failure or rate-limit rejection with no alerting; the classic failure for tracking wrappers.
• Constraint drift — ^2.8 auto-resolving to a release the runtime cannot satisfy, breaking deploys at install time rather than at runtime.
• Post-upgrade class/alias errors — facade or binding not resolving after a framework major bump.
• Config cache staleness — stale cached config after key changes.
• Deprecation-to-error escalation — PHP 8.4 deprecations in adjacent packages surfacing after the floor raise.

Ramp-up. Learning the package itself is negligible — a Laravel developer is productive in well under a day (config, env keys, dispatch a tracked event). The real cost is concentrated entirely in the platform upgrade programme: PHP 8.4 remediation plus Laravel 12 migration, which is a multi-week effort for a non-trivial application and should be scoped and resourced as such. Frame the decision as "are we doing the Laravel 12 upgrade now?" — not "should we take this package update?" The package is merely the forcing function.