Statamic Funnels Laravel Package

Technical Evaluation

Architecture fit This release changes the package's dependency posture. Where v1.24.0 was a self-contained Control Panel navigation change, v1.25.1 makes goldnead/statamic-flow-canvas ^1.6.1 a declared requirement and rebuilds the CP bundle against it. The change is still additive at the application level — no migration, no config, no public PHP API change — but the addon is no longer standalone: it now ships shared canvas components whose presentation contract is owned by a sibling package.

The substantive architectural detail is the CSS shift. Canvas components previously relied on Tailwind utility classes that resolved only because a neighbouring addon (or the host app) happened to define them; they now carry plain, package-scoped CSS. That is a decoupling win — rendering is deterministic on an install with this addon alone — but it converts an implicit, ambient styling dependency into an explicit one. Any installation that styled the canvas by targeting Tailwind utilities on these components is now styling against names it no longer controls.

Integration feasibility High, with one new precondition. Adoption remains a Composer bump with no migration and no config key. The only new work is dependency resolution: flow-canvas ≥1.6.1 must be satisfiable alongside whatever else is pinned in the lockfile, and a visual pass over the CP is warranted to confirm the restyled components look correct in the target environment — particularly under a custom CP theme or dark mode, which the release note does not mention.

Technical risk Low overall, but the risk profile has shifted from "silent cosmetic no-op" toward "dependency resolution and visual regression":

• flow-canvas is now a hard requirement. An application or another addon pinning flow-canvas below 1.6.1 will block this upgrade at composer update, which is a visible failure but a deploy-blocking one.
• The release note does not state whether the constraint is require or suggest. If it is soft, the CSS-isolation benefit silently disappears on installs without flow-canvas, and the addon reverts to the ambient-Tailwind problem the release is meant to fix.
• The class names emitted by the new plain CSS are not documented. If they are not namespaced, they can collide with host CP styles; if they are namespaced but consumers had overridden prior utility classes, those overrides stop applying.
• Two cross-package couplings now exist — statamic-brand-context for navigation, flow-canvas for presentation — and neither contract is described as versioned or covered by a deprecation policy in the material available.
• The unresolved questions from the prior assessment (brand-context constraint declaration, orphaned nav entries, permission behavior) are neither answered nor invalidated by this release.

Key questions

• Is flow-canvas a require or a suggest? The release note reads as a hard requirement but does not say.
• Are the new plain CSS class names prefixed/namespaced, and is the class-name surface treated as public API?
• Does the restyle cover dark mode and the standard Statamic CP theme, or only the default light theme?
• Does the bundle rebuild change any published asset filenames or require a vendor:publish/asset republish step? The note says only "bundle is rebuilt."
• Is statamic-brand-context ≥1.16 now declared as a constraint too, or does the nav integration remain opportunistic?
• Are there tests for the standalone install (this addon + flow-canvas, no other addons), which is the scenario this release targets?

Confidence remains directional: still no code, changelog history, or compatibility matrix — one release note.

Integration Approach

Stack fit Unchanged in kind: a Composer-installed Statamic/Laravel addon, administered through the Control Panel, orthogonal to application code, content models, and front-end rendering. What is new is an asset-layer dependency — the CP bundle is prebuilt and consumed as-is, so no Node toolchain is introduced on the consumer side, but CP styling is now governed by a package pair rather than this addon alone.

Migration path

1. Resolve the target state for both siblings: flow-canvas ≥1.6.1, and (if the prior release's layout is wanted) statamic-brand-context ≥1.16.
2. Bump the addon constraint and run composer update for this package plus goldnead/statamic-flow-canvas. If the lockfile pins an older flow-canvas, upgrade it first or in the same operation.
3. No artisan migrate, no config publish. Run the standard post-deploy config:clear/view:clear; add a CP asset/cache clear if the bundle is served through a cached asset pipeline.
4. In a non-production environment, visually verify the CP canvas surfaces — control bar divider, node actions, section headers, adder icon — under the themes and roles actually in use.
5. Roll back by reverting the lockfile entries for both packages.

Compatibility Backwards compatible for application code and data: no schema, no config, no API. Forward compatibility is now two-dimensional — flow-canvas's CSS class contract and brand-context's [section, name] contract. The most likely compatibility friction is a third addon constraining flow-canvas below 1.6.1, which surfaces as a Composer conflict rather than a runtime error. Visually, the release is a deliberate fix but an observable change; treat it as cosmetic-but-user-visible rather than a no-op.

Sequencing Ship flow-canvas ≥1.6.1 first or in the same deploy as this addon, then this addon. Keep the brand-context navigation change in a separate window if possible: combining a CP layout change with a CP restyle in one release makes any visual anomaly ambiguous to diagnose and to attribute. On staging, capture CP screenshots before and after, verify each admin role, and only then promote. If flow-canvas cannot be moved in the same window, do not upgrade this addon — unlike the previous release, this one is not a safe no-op.

Operational Impact

Maintenance Low, but the dependency surface has doubled. The addon's release cadence is now coupled to flow-canvas releases for styling correctness, and to brand-context for navigation placement. Release planning should track all three and treat a flow-canvas minor bump as a potential trigger for a rebuild here.

Support Mixed near term. The intended outcome — canvas components rendering correctly on installs where no neighbouring addon supplies Tailwind — should reduce "broken layout in the Control Panel" tickets, which are otherwise hard to reproduce. The transition cost is a wave of "the Control Panel looks different" reports and stale screenshots. Documentation should record both the flow-canvas and brand-context versions that determine what an admin sees, and support staff should be able to read those from composer.lock without escalating.

Scaling Negligible. Control Panel CSS and nav registration only; no bearing on content delivery, queue throughput, or database load. The added CSS weight is confined to the CP bundle and is not served to front-end visitors.

Failure modes

• Composer conflict (most likely new failure): a pinned flow-canvas below 1.6.1 blocks the upgrade. Visible, deploy-blocking, and resolvable — but it will surface as an unexpected delay if not pre-checked.
• Silent styling loss: if the flow-canvas constraint is soft, installs without it render the canvas with the old ambient-Tailwind dependency, and the fix does not apply. The failure is visual and easy to misattribute to this addon.
• CSS regression or override loss: namespacing collisions, dark-mode gaps, or third-party CP customizations that targeted the old Tailwind utility classes stop applying. Cosmetic, but admin-facing.
• Partial upgrade: addon bumped, flow-canvas not — components render without their own CSS. Highest-risk intermediate state; avoid by upgrading both together.
• Orphaned settings entry (carried over): parent nav entry absent or renamed by brand-context. Still the highest-impact navigation failure and still worth an explicit test case.
• Permission regression (carried over): if the parent nav entry is gated by a permission the settings page previously was not, roles can lose access to configuration.
• No data-loss or runtime failure modes: no migration, no schema change, no config key; blast radius remains the Control Panel.

Ramp-up Near zero for developers — no new API, no config to document, and the bundle is prebuilt. The operational addition is a checklist item: environment verification should now record both goldnead/statamic-flow-canvas (≥1.6.1 for correct canvas styling) and statamic-brand-context (≥1.16 for the consolidated settings navigation), with a one-paragraph briefing for administrators on why the Control Panel's appearance and menu layout may differ between environments.