Statamic Widget Newest Users Laravel Package

Technical Evaluation

Architecture fit This package sits in the Statamic addon/bridge layer of a Laravel application — it depends on Statamic's addon service provider contract, its CP/fieldtype/tag APIs, and by extension the underlying Laravel version. v1.2.0's headline change — Statamic v5 support — is therefore an ecosystem alignment release rather than a product feature. The architectural question is whether v1.2.0 is a dual-support release (Statamic 4 and 5 in one constraint set) or a hard cutover to Statamic 5. That distinction determines whether this is a low-risk additive upgrade or a coordinated platform migration.

Integration feasibility Feasible but non-trivial. Statamic 5 moves the platform floor to PHP 8.2+ and Laravel 10/11, so consuming this package at v1.2.0 implicitly forces a Laravel and PHP upgrade on any host application still on Statamic 4. Composer constraint resolution (statamic/cms: ^4.0|^5.0 vs ^5.0) is the first thing to verify. If the package maintains a single branch with union constraints, integration is a routine composer update plus regression testing. If it uses a separate 5.x branch, we are choosing between two maintained lines.

Technical risk

• Medium. The single-line release note ("Statamic v5 Support") gives no detail on breaking changes, deprecations, minimum PHP/Laravel versions, or whether Statamic 4 remains supported.
• Statamic major versions routinely change Antlers behavior, fieldtype rendering, CP asset registration, and the addon manifest/bootstrap contract. A package that merely loads under v5 may still misbehave in templates or the control panel.
• Transitive dependency risk: v5-era addons often bump shared packages (e.g. statamic/stringy, Flysystem, laravel/framework), which can conflict with other addons in a real site.
• Test coverage risk: without a published CI matrix, we cannot confirm v5 is tested against the same range as v4.

Key questions

1. Does v1.2.0 support Statamic 4 and 5 simultaneously, and until when is v4 supported?
2. What are the minimum PHP and Laravel versions for this release?
3. Are there breaking changes in the package's own public API (tags, fieldtypes, config keys, published views/assets)?
4. Is there an upgrade guide, and does the repo publish a CI matrix covering Statamic 4 + 5?
5. Is there a documented deprecation/EOL policy for the Statamic 4 line?

Integration Approach

Stack fit Target stack is Laravel 10/11 + PHP 8.2+ + Statamic 5. Any application on Statamic 4 / Laravel 9 must either stay on the prior package version or take on the full platform upgrade. This package is a follower dependency — it should be upgraded after the host platform, not before.

Migration path

1. Inventory current versions: composer show for statamic/cms, laravel/framework, PHP, and this package.
2. Read the package changelog/upgrade guide (not just the release title) for breaking changes.
3. In a branch: upgrade Laravel and PHP to the Statamic 5 floors, then composer require Statamic 5 and this package at ^1.2.
4. Run the app's own test suite plus manual smoke tests on every CP surface and Antlers template the addon touches.
5. Stage → production, with a rollback pin to the previous package tag.

Compatibility Treat v1.2.0 as semver-minor for the package but semver-major for the platform. Confirm the constraint allows a clean composer update without --with-all-dependencies surprises. Watch for other addons in the same site that have not yet shipped Statamic 5 support — this is the most common blocker in practice.

Sequencing Platform first (PHP → Laravel → Statamic), addon second, custom code third. Do not attempt a partial upgrade. If multiple Statamic addons are in play, upgrade them as a batch once each has a v5-compatible tag; otherwise Composer will deadlock on mutually exclusive constraints.

Operational Impact

Maintenance Dual-support (v4 + v5) roughly doubles the CI matrix if maintained. Establish now which line we track and how quickly we drop Statamic 4. Budget for a follow-up patch release: v5 support announcements are frequently followed by 1.2.x fixes for CP/Antlers edge cases.

Support The release note is insufficient for support triage. Request or produce an internal upgrade note covering prerequisites, breaking changes, and known issues. Ensure the team knows the minimum PHP/Laravel versions, since "it won't install" tickets will otherwise be misdiagnosed as a package bug rather than a platform-floor mismatch.

Scaling Not a runtime scaling concern; it is a release cadence concern. Pinning to ^1.2 is safe. Avoid dev-main while the v5 line stabilizes. If the package is load-bearing across multiple sites, standardize one version across the estate to keep patching tractable.

Failure modes

• Composer dependency deadlock with other v5-incompatible addons.
• Silent control-panel or Antlers regressions that pass install but fail at render time.
• Cached addon manifests / config after upgrade — require php artisan statamic:stache:clear and config:clear in the deploy runbook.
• Stale published assets/views from the pre-upgrade package version.
• Rollback complexity if the host application has already migrated to Laravel 11, since the previous package tag may not support it.

Ramp-up Low for developers already fluent in Statamic 4 — concepts carry over. The real ramp-up cost is the Statamic 5 platform delta (Laravel 11 conventions, PHP 8.2 typing, any Antlers changes), which is a team-level learning cost independent of this package. Plan a short internal knowledge-share before the first production migration.