Picturecomparator Widget Laravel Package

Technical Evaluation

Architecture fit. There is a fundamental mismatch in the request framing: this is not a Laravel or framework-agnostic PHP package. friendsofvictoire/picturecomparator-widget is a Symfony bundle written for Victoire, a widget-driven Symfony CMS. It integrates through Symfony-specific extension points — a bundle class registered in AppKernel, DI service definitions, a Widget model extending Victoire's AbstractWidget, Twig template overrides, and Doctrine-persisted widget instances bound to a WidgetMap. None of those concepts have an equivalent in Laravel's service container, package discovery, Blade pipeline, or Eloquent layer. Architecture fit against a Laravel codebase is effectively zero without a rewrite; the bundle is a rendering feature, not a portable library.

Integration feasibility. What the package actually does — render a before/after image comparison slider — is a small, well-understood front-end pattern requiring two image references, a container element, and a JS handler. That logic is roughly 100–250 lines of Twig/Blade plus a comparator script. Porting the bundle would mean reimplementing Victoire's widget registration, persistence, and form-type plumbing for no functional gain. The realistic integration is a Blade partial + a Livewire/Alpine component + a media field on the model, not this dependency.

Technical risk. High and asymmetric:

• Abandonment. Last release 2018-05-24, single-digit stars, zero dependents. No maintainer, no issue triage, no security response path.
• EOL transitive surface. A 2018 Symfony-era bundle pulls Symfony 2.8/3.x constraints, old Twig, old Doctrine, and possibly Assetic — a stack of packages that reached end-of-life between 2018 and 2021 and carry unpatched advisories. Installing it would almost certainly require --ignore-platform-reqs or a PHP downgrade, which is a non-starter on a modern runtime.
• PHP version lock. Composer constraints from that era typically cap at PHP 7.x, conflicting with PHP 8.2/8.3 targets.
• Bus factor / provenance. "FriendsOfVictoire" is a community successor org to a dormant CMS; there is no vendor relationship to lean on.

Key questions.

1. Is the ticket mis-tagged as Laravel, or is there an actual Symfony service in our estate? If the latter, is Victoire itself still supported anywhere?
2. What is the real requirement — a marketing-page image reveal, or a product feature with CMS-author workflows? The answer changes the build-vs-adopt calculus entirely.
3. Who owns the transitive dependency audit if we adopt, and what is the remediation SLA for an unmaintained dependency?
4. Are there accessibility (keyboard operability, contrast on the divider) and mobile-touch requirements the 2018 implementation does not meet?

Integration Approach

Stack fit. Poor to nonexistent. The package's runtime assumptions (Symfony kernel, DI compiler passes, Twig, Doctrine widget entities) do not map onto Laravel. There is no maintained Symfony-to-Laravel bridge that would make a Victoire widget bundle usable inside an Illuminate application. Treat this as incompatible rather than "needs adaptation."

Migration path. Recommended path is reimplement, do not port:

1. Add a media pair to the relevant Eloquent model (e.g., before_image_id, after_image_id) or reuse an existing media/asset abstraction.
2. Build a Blade component wrapping an actively maintained comparator library (e.g., img-comparison-slider, beerslider, or a small custom Alpine component) — MIT-licensed, ~5–10 KB, no PHP dependency.
3. Expose it as an admin-editable block via the CMS/block system already in use (Filament, Nova, Statamic, or a custom block registry).
4. If a Symfony service genuinely exists, isolate it behind an HTTP boundary rather than sharing code.

Estimated effort for the reimplementation: 2–4 developer days including styling, responsive behavior, and accessibility. Estimated effort to port the bundle: 2–3 weeks plus indefinite maintenance of a fork with no upstream.

Compatibility. Assume the bundle is incompatible with PHP 8.x and current Laravel versions until proven otherwise. Any evaluation that proceeds should begin with a throwaway composer require in a sandbox to confirm the constraint resolution failure — that artifact alone typically closes the ticket.

Sequencing. Do not sequence this into a roadmap as a dependency. Instead: (1) confirm the requirement with the requesting stakeholder, (2) prototype the Blade/Alpine comparator against real assets, (3) review output against design and accessibility, (4) ship as first-party code. Total elapsed time is shorter than a dependency-approval review.

Operational Impact

Maintenance. This is the decisive factor. Adopting a 2018 abandoned bundle transfers full maintenance ownership to us on day one: security patching, PHP version bumps, Twig API changes, and comparator-library upgrades all become internal work. A first-party 200-line component has a maintenance cost roughly one to two orders of magnitude lower and no external failure surface.

Support. No upstream support channel, no release cadence, no CVE feed. Internal on-call would have no escalation path and no vendor to pressure. For a user-facing rendering feature this is tolerable only if we own the code.

Scaling. The feature is client-side rendering of two images; it does not meaningfully stress application infrastructure. The real scaling consideration is image delivery — responsive srcset, modern formats (AVIF/WebP), and CDN offload for the large paired assets. Those concerns live in our media pipeline and are untouched by this package.

Failure modes.

• Dependency resolution failure at install (most likely outcome; low blast radius, caught immediately).
• Runtime breakage on framework upgrade — a dormant bundle will not track Symfony/Laravel major versions, so it silently becomes the thing blocking a platform upgrade.
• Unpatched CVE in a transitive dependency with no upstream fix; remediation means forking.
• Silent visual regression — no test coverage, no CI, so rendering changes surface in production.
• Accessibility and mobile-touch gaps — 2018-era sliders frequently lack keyboard operability and touch handling that current WCAG 2.2 expectations require.

Ramp-up. Negligible either way — the domain (an image comparison slider) is trivial to onboard an engineer onto. That is precisely the argument against taking on dependency risk for it. There is no scenario where the bundle's accumulated logic represents meaningful leverage we would lose by rebuilding.

Verdict. Decline adoption. The package is a Symfony-CMS-specific UI widget, six-plus years unmaintained, with no dependents and no viable path into a Laravel stack. Replace with a first-party Blade/Alpine component backed by an actively maintained comparator library; the build cost is measured in days and eliminates the entire risk surface. Flag the "Laravel package" classification in the registry as inaccurate metadata so this does not resurface in future evaluations.