Statamic Flow Canvas Laravel Package

Technical Evaluation

This release establishes the baseline assessment for the package at v1.6.1. The change is architectural rather than cosmetic: seven shared UI components (Canvas, AdderNode, ControlBar, InsertableEdge, NodeCard, NodeLibrary, PropertiesSection) no longer depend on host-generated Tailwind utilities for their core layout and colour. They now use package-owned fc- classes and scoped <style> blocks, with dark-mode colours via :global(.dark) and CSS variables instead of hex values.

• Architecture fit: Improved for Laravel/PHP applications that do not scan package paths in their Tailwind build, or that do not use Tailwind at all. The package is less coupled to the host’s CSS pipeline for the affected components. Remaining Tailwind utilities outside the listed components mean the package is not fully Tailwind-independent.
• Integration feasibility: Likely low-friction for a normal Composer update plus frontend asset rebuild. No PHP/API/database changes are indicated. The main integration work is CSS verification and updating any host overrides that targeted Tailwind utility classes on the affected elements.
• Technical risk: Medium-low. The release fixes a real isolation defect, but it changes the styling contract for seven components. Hosts that overrode utility classes, relied on Tailwind selector specificity, or assumed package styles were generated by their own build may see visual regressions. Scoped <style> blocks can also interact with CSP policies and may duplicate CSS across component instances.
• Key questions: Which Laravel/PHP versions are supported? Is the frontend stack Vue, Blade, Livewire, Inertia, or mixed? Are fc- classes and CSS variables now public API? Are CSS variables documented with fallback values? Can inline/scoped styles be extracted or nonce-enabled for strict CSP? Does :global(.dark) require a specific ancestor class contract? Are there visual regression tests beyond tests/js/plain-css.test.js?

Integration Approach

• Stack fit: Best fit for Laravel applications using the package’s frontend components in Blade/Livewire/Inertia/Vue contexts. It reduces the requirement that the host’s Tailwind content configuration include package paths for these seven components, but hosts still need Tailwind for any remaining utility-based components.
• Migration path: Update the Composer dependency to v1.6.1, rebuild frontend assets, and inspect the seven affected components in both light and dark modes. Replace any host CSS overrides that target former Tailwind utilities with overrides against the new fc- classes or CSS variables. Confirm the host still provides the expected .dark ancestor if dark mode is used.
• Compatibility: No database migration or PHP API change is indicated. The release is frontend-asset sensitive: stale compiled assets, cached views, or CDN-cached CSS can mask the change. Tailwind configuration can likely stop scanning package paths for the affected components, but should retain any paths needed by non-migrated utilities.
• Sequencing: Pin v1.6.1 in a development branch; run the package’s JS test suite including tests/js/plain-css.test.js; perform visual regression checks on all seven components; validate CSP behavior for scoped style blocks; then promote to staging and production. For teams with custom themes, schedule a short CSS override audit before rollout.

Operational Impact

• Maintenance: Lower Tailwind coupling reduces a class of “host build did not scan package” failures, but it shifts responsibility to the package’s own CSS contract. The fc- class names and CSS variables should be treated as versioned public API; undocumented changes would create upgrade friction.
• Support: Expect questions from hosts whose custom styles targeted Tailwind utilities on these components. Release notes should explicitly call out the selector migration path and dark-mode/CSS-variable expectations. CSP-related reports are possible if scoped <style> blocks are blocked or restricted.
• Scaling: The change should scale acceptably for typical Laravel admin/editor screens. Watch for duplicated scoped CSS if many component instances render, and verify that CSS variables are defined at an appropriate scope so theming remains centralized.
• Failure modes: Missing or undefined CSS variables causing fallback colours; dark mode not applying because no .dark ancestor exists; host global CSS overriding fc- classes; CSP blocking inline/scoped styles; stale assets serving old Tailwind-dependent markup; custom overrides still targeting removed utility classes.
• Ramp-up: Low for teams consuming the package as-is. Medium for teams with heavy visual customisation, design-system overrides, strict CSP, or multiple frontend stacks. A focused visual QA pass and a CSS override audit are the main onboarding costs.