Statamic Flexible Width Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic addon, so its architectural fit is conditional on the host application already running Statamic on Laravel rather than on a standalone Laravel install. Addons in this ecosystem register through a service provider and addon-manifest, and may surface functionality via Antlers tags/modifiers, fieldtypes, control-panel Vue components, or scheduled/console commands. The relevant fit question is not whether it works with Laravel generally, but whether its CP assets, blueprint/content schema expectations, and any published config or migrations align with the host site's Statamic version. The 2.0.0 release note indicates a hard coupling to the Statamic major version rather than an independent lifecycle, which is the dominant architectural characteristic a TPM should plan around.

Integration feasibility. Feasible but tightly sequenced. A major version bump whose only stated change is "Statamic 6 support" almost certainly means the composer.json constraint moved to statamic/cms: ^6.0, which makes installation on a Statamic 5 site impossible without also upgrading the CMS. Conversely, a site that has already moved to Statamic 6 cannot use any earlier 1.x line. That is a coupled upgrade, not an independent dependency addition — feasibility is therefore really a question of whether the host site's Statamic upgrade is feasible.

Technical risk. Medium to high until clarified, concentrated in four areas:

• Scope of the major bump. Whether 2.0.0 is purely a compatibility widening (supporting 5 and 6) or a hard cutoff at 6. The wording suggests the latter; a widened constraint would normally ship as a minor.
• Undocumented breaking changes. Release notes list one line. Addon majors frequently also carry namespace changes, renamed config keys, altered tag signatures, or changed fieldtype data formats that are not called out. Silent behavior changes are the highest-cost failure mode for a CMS addon because they can alter rendered content.
• Downstream platform constraints. Statamic 6 will carry its own Laravel and PHP minimums, so this addon release indirectly raises the floor for the whole application stack.
• Upgrade path for existing installs. No migration guide or deprecation notice is referenced, which raises the risk of a stalled upgrade for any site currently pinned to 1.x.

Key questions for the maintainer.

1. Does ^2.0.0 still resolve against Statamic 5, or is 6 now the exclusivity floor?
2. Is 1.x still receiving security and bug fixes, and for how long? What is the support window?
3. What are the declared PHP and Laravel minimums for 2.0.0?
4. Beyond the dependency constraint, are there API, config, tag, or stored-data breaking changes? Is there an upgrade guide or changelog diff?
5. Does Statamic 6 require content/blueprint migrations that this addon participates in?
6. What is the automated test matrix coverage across Statamic 5 and 6?

Integration Approach

Stack fit. Only relevant to teams on the TALL-adjacent stack — Laravel plus Statamic as the content layer. Teams on plain Laravel, or using a different CMS, should treat this release as out of scope. Confirm the addon's role before committing: whether it is load-bearing for content rendering (tags/fieldtypes — high blast radius) or auxiliary (CP tooling, imports — low blast radius).

Migration path. Treat the addon upgrade as a downstream step in a Statamic platform upgrade, never as a standalone bump. The realistic path is: Statamic major upgrade in a branch → resolve addon compatibility one package at a time → verify content rendering and CP behavior → merge. Attempting to bump this addon first will produce dependency-resolution failures that obscure the real ordering.

Compatibility. Pin both dimensions explicitly. Record the current Statamic, Laravel, and PHP versions and the currently installed addon constraint, then check the 2.0.0 composer.json before touching the lockfile. If the site cannot move to Statamic 6 yet, the correct action is to hold at 1.x and confirm that line is still supported — not to attempt a partial upgrade.

Sequencing.

1. Inventory: which sites/projects depend on this addon, and which are on which Statamic version.
2. Read the 2.0.0 composer.json and full changelog diff, not just the release note.
3. Confirm 1.x support status and end-of-life timing.
4. Upgrade Statamic in a branch; validate core content rendering without the addon first.
5. Add the addon 2.0.0, run the site's content regression checks, and inspect CP screens that use the addon.
6. Roll out per-project, lowest-traffic or least-critical first.

Operational Impact

Maintenance. The addon now tracks Statamic majors, which means its release cadence is inherited from the CMS. Budget for a coordinated upgrade roughly each time Statamic ships a major, and expect that window to be short enough that deferral is not a real option. Pin the addon at a minor level and upgrade deliberately rather than floating.

Support. The critical unknown is the overlap period for 1.x. If 1.x is effectively frozen at the 2.0.0 release, any site that cannot reach Statamic 6 in the near term is running an unsupported dependency — that is a tracked risk with an owner and a deadline, not a footnote. Escalate to the maintainer in writing and record the answer.

Scaling. Addon-level scaling concerns are mostly CP and rendering performance: added tags or fieldtypes execute on every request that renders them, and CP assets add to the editor payload. Nothing here suggests infrastructure-level scaling risk, but if the addon does index-time or query-time work, re-benchmark against Statamic 6 rather than assuming parity, since a CMS major can change the underlying query and cache layers.

Failure modes to watch.

• Composer resolution conflict blocking the entire platform upgrade, with the addon as the last unresolvable constraint.
• Silent rendering differences after upgrade if tag or fieldtype output changed without a documented note.
• CP asset or Vue version mismatch against Statamic 6's control panel, showing as a blank or broken addon screen rather than a clean error.
• Stale cache or search index after a schema change, producing partial or missing content that only appears in production traffic.
• Divergence across a multi-site portfolio where some sites upgrade and others are stranded on 1.x, doubling the support surface.

Ramp-up. Low for developers familiar with Statamic addon conventions — the integration surface is conventional. The real cost is upgrade coordination and regression testing, not learning the package. Allocate the effort to content regression coverage, since that is the only reliable way to catch undocumented behavior changes in a CMS addon, and stage the upgrade before production for any site where the addon affects rendered output.

Assessment confidence. Low. This evaluation rests on a single-line release note with no prior assessment on record. The recommendations above should be treated as a risk-shaped plan pending answers to the key questions, particularly the 1.x support status and the true scope of breaking changes.