Fancybox Bundle Laravel Package

Product Decisions This Supports

• Lightbox / media-viewer feature scoping. The capability this package wraps — modal image galleries, inline HTML overlays, iframe content panes — is a real, recurring product need (product galleries, onboarding modals, document previews). This package itself is only relevant as a decision input, not a dependency.
• Build vs. buy vs. vendor. The honest read: FancyBox is a client-side jQuery plugin, and this bundle does almost nothing beyond registering its assets and a Twig hook. That collapses the build/buy question into "drop the JS/CSS into our layout" — roughly a dozen lines of Blade or Twig. No dependency needed.
• Framework-fit correction. Despite being catalogued alongside PHP packages, this is a Symfony2 bundle, not a Laravel package. It cannot be installed into a Laravel app via Composer autodiscovery or service providers. Any roadmap item assuming "we'll pull this in" for a Laravel codebase is based on a false premise and should be corrected before it reaches sprint planning.
• Legacy platform triage. Its only legitimate signal is as an artifact of a Symfony 2.x estate — Symfony 2 reached end-of-life in 2018. Zero stars, zero dependents, and a zero score mean no community safety net: no security patches, no PHP 8 compatibility work, no maintainer. If this appears in a dependency audit, treat it as a modernization trigger, not a component to retain.
• Tech-debt prioritization. Where a legacy Symfony 2 app still ships this, the decision it should drive is "when do we replace FancyBox 1.x/2.x," since current FancyBox (v5) is dependency-free and modern browsers offer native <dialog>. Bundling an unmaintained jQuery 1.x-era plugin is a standing accessibility and XSS-surface cost.
• Vendor-risk policy input. A useful calibration case for a rule like "no new dependencies with zero dependents and no release in N years." Cheap to state, easy to apply, and this package fails it unambiguously.

When to Consider This Package

Consider only if all of the following hold:

• The application is already running Symfony 2.x and cannot be upgraded this cycle.
• You need FancyBox wired up in the next few hours and accept it as frozen, unpatchable code.
• The use is internal, low-traffic, non-customer-facing (admin back office, internal tooling) where accessibility and CSP compliance are not gating.
• You are prepared to vendor the source into your repository rather than depend on a Packagist release that will never be updated.

Look elsewhere — essentially every other case:

• Any Laravel application. Wrong framework; the bundle's service provider, DI config, and Twig extension are inert here. Use @vite plus a maintained lightbox.
• Symfony 5/6/7 or any modern PHP stack. Incompatible service definitions and PHP-version drift; not worth the port.
• Customer-facing UI. FancyBox 1.x/2.x carry known XSS vectors and poor screen-reader semantics. Modern FancyBox 5 or native <dialog> + CSS is the safer, cheaper route.
• Anything requiring a maintenance commitment. Zero stars, zero dependents, no recent activity: there is no one to escalate a CVE or a browser regression to.
• Teams already on Alpine, Livewire, Inertia, or a React/Vue front end. A jQuery plugin is the wrong layer entirely; use your component library's modal primitive.

Where a lightbox is genuinely needed, the shortlist is: FancyBox 5 (vanilla JS, actively maintained), PhotoSwipe, Glightbox, or native <dialog> if requirements are simple. All are installable in a Laravel or Symfony app in under an hour with no wrapper package.

How to Pitch It (Stakeholders)

For executives — recommendation: do not adopt.

This is a thin wrapper around a jQuery lightbox plugin, packaged for Symfony 2 — a framework version that has been unsupported for years. It has no stars, no downstream users, and no maintenance. Adopting it would add a permanently unpatchable dependency to gain roughly ten lines of asset registration. There is no cost saving and no capability we can't get in an afternoon from a maintained library.

The one thing worth escalating: if this package surfaced because it's already inside a legacy Symfony 2 system, that system is our actual risk. It runs an EOL framework with EOL front-end libraries. I'd like a line item to scope that migration, because the alternative is discovering it during a security review.

For engineering — the technical case in three points.

1. It isn't a Laravel package. It's a Symfony2 bundle: a DI extension, a Resources/config service definition, and a Twig extension that registers FancyBox assets. None of that executes under Laravel. If a ticket says "install this in the Laravel app," the ticket is wrong.
2. The value-add is negligible. Everything the bundle does, we can do directly — pull FancyBox 5 from npm, import it in app.js, and call Fancybox.bind() from a small Blade component or an Alpine directive. That's a component we control, test, and upgrade.
3. The risk is asymmetric. Zero dependents means no one else is exercising the code path; if a browser update or a jQuery CVE breaks it, we own the fork. FancyBox 5 removes the jQuery dependency entirely and ships maintained; native <dialog> removes the dependency question altogether.

Ask: reject the dependency, spend the hour on a first-party lightbox component, and — separately — flag the Symfony 2 estate for a modernization assessment.