Statamic Fa Widget Laravel Package

Technical Evaluation

Scope and confidence. The only signal available is a single-line release note: "Statamic 5!". There is no prior assessment and no dependency, source, or issue-tracker data supplied. This evaluation is therefore provisional and derived from what a v2.0.0 major bump tied to Statamic 5 implies for a Laravel/PHP package in the Statamic addon ecosystem. Confirm the specifics below against the package's composer.json, CHANGELOG, and upgrade guide before committing to a plan.

Architecture fit. The package is almost certainly a Statamic addon — a Composer-installed Laravel package that registers a service provider and hooks into Statamic's addon discovery, config publishing, and extension points (tags, modifiers, fieldtypes, widgets, or a control-panel UI). That is a good architectural fit for a Laravel application already running Statamic: it inherits Laravel's container, config, queue, and event system rather than introducing a parallel runtime. The v2.0.0 major bump is best read as a compatibility-line change, not a feature release: the addon has moved its constraint to statamic/cms: ^5.0 and consequently dropped Statamic 4 (and likely PHP 8.0 and Laravel 9) from its support matrix.

Integration feasibility. Mechanically straightforward — a Composer version bump plus the standard addon install steps (php artisan statamic:addons:discover/vendor:publish where applicable). The real work is not installation but the transitive constraint solve: Statamic 5 requires a modern Laravel and PHP baseline, so adopting this addon version can force an application-platform upgrade. Feasibility is high; effort is dominated by the host application, not the package.

Technical risk.

• Breaking API surface (high). Statamic majors routinely change addon-facing APIs and control-panel conventions (notably the Vue 2 → Vue 3 migration in the CP for Statamic 5). If this package ships CP assets, its front-end build is a genuine rewrite surface, and regressions there are typically visual/behavioural rather than exception-throwing — the hardest kind to catch.
• No dual-support guarantee (unknown). A ^5.0-only constraint means the addon cannot be installed alongside Statamic 4. Anyone mid-upgrade is stranded on 1.x.
• Content/data compatibility (unknown). If the package owns a fieldtype or stores augmented data, Statamic 5 changes may alter serialization or the augmentation pipeline. Rollback after writing data in the new format is the scenario to design for.
• Test coverage signal (unknown). Absent a CI matrix covering Statamic 5 × supported Laravel/PHP versions, a one-line release note is weak evidence of validation.

Key questions.

1. Does v2.0.0 support Statamic 4 and 5 concurrently, or is it 5-only? What is the exact composer.json constraint set (Statamic, Laravel, PHP)?
2. Is there a published upgrade guide, and does it enumerate breaking changes for consumers (config keys, class names, template/tag signatures, CP routes)?
3. Are there data or content migrations — fieldtype schema, YAML front-matter, stored settings — and are they reversible?
4. Will 1.x continue to receive security and bug fixes, and for how long?
5. Does the project ship CP assets, and if so were they rebuilt for Vue 3 / current Vite tooling?
6. What does CI actually exercise for this release (matrix breadth, integration vs. unit tests)?

Integration Approach

Stack fit. Target state is a Laravel application on the current supported Laravel line with PHP 8.1+ running Statamic 5, and this package at ^2.0. If the host app is on Statamic 4, this package version is not installable — the two upgrades are coupled and must be planned as one programme of work, with Statamic 5 as the gating item.

Migration path.

1. Inventory the host application: current Statamic, Laravel, and PHP versions; whether this addon is load-bearing (public-facing templates, editorial workflow, or stored content) or peripheral.
2. Pin the current 1.x version in composer.json and confirm a green build — establishing a known-good rollback point before touching anything.
3. Upgrade Statamic to 5 in isolation, with the addon on 1.x if compatible or temporarily disabled, resolving framework-level breaks first.
4. Add this package at ^2.0, re-publish any config, re-run addon discovery, clear caches (config:clear, view:clear, cache:clear, and Statamic's own caches), and rebuild front-end assets.
5. Execute a functional regression pass over every surface the addon touches, plus a content round-trip test (edit → save → render → search index) if it stores data.

Compatibility. Build an explicit matrix of Statamic × Laravel × PHP for 1.x and 2.x and publish it. Consumers need one authoritative table to decide whether to upgrade now, defer, or fork their integration. Where the addon exposes template tags or modifiers, snapshot-test rendered output against the pre-upgrade baseline — this catches the silent behavioural drift that unit tests miss.

Sequencing. Treat the upgrade as a dependency-ordered chain: platform (PHP/Laravel) → Statamic 5 → addon 2.x → application code → content. Do not parallelise the Statamic and addon steps; a failure in either is indistinguishable if both move at once. Run it in staging against a production data snapshot first, and only then schedule the production cutover with a maintenance window and a rehearsed rollback (revert code and restore the pre-upgrade database/content backup).

Operational Impact

Maintenance. Expect a two-branch maintenance burden for as long as 1.x is supported: security fixes and Statamic 4 compatibility on one line, Statamic 5 work on the other. That is a real, recurring cost, and it is the single most important thing to clarify with the maintainer — a 1.x line that is effectively abandoned changes the risk calculus for anyone who cannot upgrade immediately.

Support. A one-line release note is insufficient documentation for a major version of a dependency that can store content. Require, at minimum: a changelog enumerating breaking changes, an upgrade guide with before/after examples, and a stated support window for 1.x. If those are absent, budget internal time to reverse-engineer the delta from the diff.

Scaling. No meaningful runtime scaling change is expected — the package runs in-process within the Laravel request lifecycle, so throughput remains a function of the host application, Statamic's caching, and any external calls the addon makes. Two things to watch at scale: whether the addon registers expensive boot-time work or uncached template tags (visible as p95 latency after upgrade), and, if it ships CP assets, the build/bundle size and Vite manifest handling in deploys.

Failure modes.

• Silent version regression. Composer resolving back to 1.x because another dependency pins Statamic 4 — the upgrade appears to succeed while the old code runs. Verify the locked version post-install, not just the requirement.
• Partial asset deploy. CP or front-end assets not rebuilt or not published to the web root, producing a broken or unstyled control panel.
• Stale caches. Old config, compiled views, or addon manifests surviving the upgrade and masking as functional bugs.
• Content-format drift. Data written by 2.x that 1.x cannot read, making rollback destructive.
• CP regressions. Vue 3-era component behaviour changes that surface as editor-facing bugs weeks after release, with no error signal.

Ramp-up. Low for developers on the happy path — the addon pattern is idiomatic Laravel and the install steps are documented ecosystem convention. The ramp-up cost sits with whoever owns the upgrade: they need working fluency with Statamic 5's breaking changes, Composer constraint resolution, and Statamic's caching layer to debug the failures above. Budget roughly one to two days of engineering for a peripheral addon on an already-compatible stack, and one to two weeks if the host application is still on Statamic 4 or if the addon is load-bearing for content or the editorial UI. Produce a short internal upgrade runbook — pre-checks, ordered steps, verification checklist, rollback trigger — before any production change; that artefact is the cheapest risk reduction available here.