Button Widget Laravel Package

Technical Evaluation

Architecture fit. victoire/button-widget is not a Laravel package. It is a Symfony bundle (Victoire\WidgetButtonBundle) that supplies a single "button" widget to the Victoire CMS page builder. Its contract is defined by Victoire's WidgetBundle, EditorBundle, and the CMS's widget rendering pipeline — none of which exist in a Laravel application. There is no service provider, no facade, and no Laravel integration surface. Architecturally, it is a plugin for a CMS that has no meaningful relationship to Laravel.

Integration feasibility. Low to nil as a dependency. It targets Symfony 2/3-era conventions and a 2019 PHP baseline; modern Laravel (10/11/12) requires PHP 8.1+ and Symfony 6/7 components. Composer resolution will fail or force pinning the entire application to an EOL stack. The only realistic path is concept reuse, not code reuse: lift the widget's domain model (label, link target, style variant, icon, open-in-new-tab) and re-implement it natively.

Technical risk. High, and the metrics corroborate it: 2 stars, 0 dependents, last release 2019-05-02, overall score 1.17, opportunity 2.48. No security patching, no maintainer activity, no issue triage, no downstream validation. Every transitive dependency it drags in (Symfony components, Victoire core) is likewise unpatched. Bus factor is effectively one, and that one is inactive.

Key questions for the requester. (1) Is there a live Victoire installation we are actually maintaining, or is this a "can we reuse this" exploration? (2) What requirement is the button widget solving — CMS block authoring? If so, the requirement is "editable button block," not "this bundle." (3) Is there budget for a fork-and-own commitment, or is this being framed as free leverage? (4) Who is the accountable owner if we take the dependency?

Integration Approach

Stack fit. Mismatch at every layer: bundle registration vs. package discovery, Symfony DI compiler passes vs. Laravel service providers, Twig-rendered widget templates vs. Blade/Livewire, and Victoire's editor UI vs. Nova/Filament. There is no shim worth writing.

Migration path. Treat it as a specification source, not a migration target. Extract the widget's inputs, validation rules, and rendering semantics from the bundle, then implement a Laravel-native block: a Blade component for render, a JSON schema for stored block config, and a Filament/Nova field or Livewire form for authoring. If an internal Victoire site exists, plan a content-export step (widget config is typically serialized per page) rather than a runtime bridge.

Compatibility. No compatible version window with current Laravel. Do not attempt to co-install; a dependency conflict at the root of the graph will cascade into the rest of the app. If code reuse is mandated, vendor the bundle's PHP into a namespaced internal package and strip the Symfony/Victoire coupling — but expect that to cost more than a rewrite.

Sequencing. (1) One- to two-day spike to read the bundle and document the widget contract. (2) Decision gate: reimplement natively vs. drop the requirement. (3) Build the Laravel-native equivalent behind the existing block/field abstraction. (4) Backfill tests and documentation. (5) If a Victoire system is live, schedule its decomposition separately — do not couple it to the Laravel work.

Operational Impact

Maintenance. Zero upstream. If adopted, we own the code, the security posture, and the PHP/Symfony upgrade treadmill indefinitely. That cost should be priced explicitly before any decision.

Support. No community to escalate to. No advisories, no issue response, no release cadence. The 0-dependents figure is a signal rather than a coincidence — nobody else has validated this path.

Scaling. The widget itself is stateless UI configuration, so it is not a scaling concern. The surrounding CMS stack it implies (EOL Symfony, unpatched dependencies) is a compliance and availability concern, particularly if it sits on an internet-facing host.

Failure modes. Composer resolution failures on upgrade; PHP 8+ deprecation and fatal errors; Symfony EOL breaking changes; unpatched CVEs in transitive packages; loss of the only maintainer; silent divergence across forks. The most likely failure is "it installs today, breaks on the next framework bump, and nobody remembers how it works."

Ramp-up. A Laravel team needs roughly a week of Symfony-bundle literacy to read the code with confidence — time better spent writing the native equivalent. Realistic effort for the recommended path: a two-day spike plus three to five engineering days for a Laravel-native button block, versus an unbounded fork-and-maintain commitment for the alternative.

Recommendation. Do not adopt as a dependency. Leverage it as a reference implementation only, and only if an editable-button block is a genuine near-term requirement.