Fos User Bundle Adapter Laravel Package

Product Decisions This Supports

• Build vs. buy for legacy auth integration: This is not a product feature; it is a thin integration shim between Yucca (a user/ACL library) and FOSUserBundle. It only becomes relevant if you are already committed to both stacks. It does not justify a roadmap slot on its own.
• Migration planning: The most actionable signal is negative. FOSUserBundle is end-of-life (Symfony 3–4 era), and this adapter has zero stars and zero dependents — meaning effectively no production validation and no community to lean on if it breaks. This package should appear in a decision log as "consider only during a legacy audit," not as a new dependency.
• De-risking an existing integration: If your codebase already wires Yucca to FOSUserBundle by hand, adopting this adapter can consolidate glue code into a maintained-style bundle boundary — a small refactor win, not a strategic one.
• Use cases it fits: Symfony (not Laravel) applications with a user model inherited from FOSUserBundle and ACL/role needs handled by Yucca. Expect it to be used for authentication-adjacent plumbing — user provider bridging, role resolution, and group/permission mapping — not for customer-facing capabilities.
• Roadmap implication: Budget for an eventual replacement of FOSUserBundle itself (Symfony Security's native user providers, or moving to a maintained alternative). Any adoption of this package should carry a sunset condition.

When to Consider This Package

Consider it only when all of the following hold:

• You are on a legacy Symfony application (not Laravel) already using both FOSUserBundle and Yucca.
• The integration currently lives in hand-rolled glue code that you want to isolate behind a bundle boundary.
• You have engineering capacity to vendor/fork it if needed, because the dependency graph is empty.

Look elsewhere — or build in-house — when:

• You are starting greenfield. Do not adopt FOSUserBundle in 2024+; use Symfony's native security user providers and a maintained ACL/RBAC solution.
• Your stack is Laravel. Despite the "PHP" tag, this is a Symfony bundle; it provides no value in a Laravel application.
• You need community support, security patching guarantees, or documentation. With 0 stars, 0 dependents, and a near-zero score, there is no evidence of maintenance, testing, or user base. Treat any adoption as taking ownership of the code.
• Authentication is security-critical for your product. An unvetted, unmaintained shim in the auth path is a liability; a bespoke, reviewed integration is safer than an unmaintained one.
• You are evaluating this as a "quick win" for a roadmap item. It does not deliver user-facing capability; it only reduces glue code in a narrowing set of legacy contexts.

Verdict for a PM: Low strategic relevance. Flag as legacy-only / do-not-adopt-greenfield, and pair any use with an explicit exit plan for FOSUserBundle.

How to Pitch It (Stakeholders)

Executives: This is a small plumbing package that connects two older authentication components on Symfony. It has no community adoption and no visible maintenance, and one of the components it depends on is end-of-life. It is not part of any growth or differentiation story. Its only rationale is short-term code hygiene inside a legacy system — so treat it as a maintenance-line item, not an investment, and fund the eventual replacement of the underlying user/auth stack instead.

Engineering: The adapter is a thin bridge between Yucca and FOSUserBundle on Symfony. Use it only if you already run both and want to pull ad-hoc integration code behind a bundle boundary; expect to own it, since the dependency graph is empty. Do not introduce FOSUserBundle into new work — it's end-of-life — and plan the migration to Symfony's native security user providers plus a maintained RBAC solution. If you do adopt it, pin the version, vendor or fork the source, and add a test around role/permission mapping, since nobody else will catch regressions for you.