Fos User Bundle Polyfill Laravel Package

Product Decisions This Supports

• Incremental auth migration vs. big-bang rewrite. The core decision this enables is whether to rip FOSUserBundle out of a legacy app in one risky release or to stage the migration. The polyfill keeps FOSUserBundle model interfaces resolvable while individual user providers, entities, and controllers are swapped out — turning a multi-week cutover into a sequence of shippable slices.
• Roadmap sequencing and capacity planning. Because it reduces the integration surface of an auth migration, it directly affects how much engineering time you have to reserve. A PM can frame it as: "one sprint of migration work instead of a quarter-long auth rewrite, with feature work continuing in parallel."
• Build vs. buy vs. glue. The realistic alternatives are (a) fork/stay on FOSUserBundle, (b) write bespoke interface shims, or (c) adopt a tiny MIT polyfill as transitional scaffolding. This package is option (c). It is not a feature dependency; it is throwaway infrastructure.
• Decommissioning and archival decisions. With 2 stars, 0 dependents, a last release in January 2020, and archived status, the PM decision is not "adopt as a dependency" but "vendor or copy in-tree, pin the version, and attach a removal ticket." That changes procurement and dependency-review conversations.
• Concrete use cases: acquired or inherited Symfony apps still coupled to FOSUserBundle; monoliths where domain User entities are type-hinted against FOS interfaces by third-party bundles; compliance/EOL-driven PHP or Symfony upgrades where auth is the blocker; portfolios where "we can't upgrade because of auth" is the standing excuse.

When to Consider This Package

Consider it when:

• You have a legacy Symfony application actively using FOSUserBundle and cannot perform a clean, single-release cut-over to native Symfony Security.
• Something in your dependency tree — a third-party bundle, a shared internal library, or a domain model used across services — type-hints against FOSUserBundle interfaces and would otherwise break during the transition.
• The rest of your stack is compatible with a 2020-era package (verify PHP and Symfony version constraints against your target runtime before committing; do not assume it runs on current PHP without checking).
• You have test coverage around authentication sufficient to catch a silent interface mismatch, and you are willing to vendor, pin, and own the code.
• You need a time-boxed bridge, measured in sprints, with a defined removal milestone.

Look elsewhere when:

• The project is greenfield, or you can migrate auth in a single planned change — use Symfony's native UserInterface and password hashing directly; the polyfill adds nothing.
• You need active maintenance, security patches, or vendor support. Archived + last release 2020 means you are the maintainer the moment you depend on it.
• You require community validation or ecosystem confidence. Two stars and zero dependents means no third-party signal; the only assurance is your own code review of a small MIT codebase.
• Your runtime has moved past the package's supported PHP/Symfony range — in that case copy the interfaces into your own codebase rather than fight the constraints.
• The "legacy" system is small enough that a rewrite is cheaper than the coordination cost of a staged migration.

How to Pitch It (Stakeholders)

For executives: We have a legacy authentication component that is blocking upgrades. This is a small, free, MIT-licensed compatibility layer that lets us move off it incrementally rather than freezing the roadmap for a full auth rewrite. Cost is effectively zero in license terms; the real cost is a bounded amount of engineering time we already have to spend. It is scaffolding, not a strategic dependency — we vendor it, pin it, and delete it when the migration completes. Risk is low and bounded: the code is small and auditable, though the project is archived and unmaintained, which we mitigate by owning a local copy and tracking a removal date.

For engineering: Treat this as a transitional interface shim, not a library. Copy it in-tree or vendor it, pin the version, write a test that asserts the interfaces your code depends on, and open a removal ticket on day one. It is explicitly not on the long-term dependency surface, and it should not appear in architecture diagrams as a component. If version constraints don't fit the target runtime, lifting the interfaces directly into our own namespace is a valid — and probably preferable — fallback.

Bottom line: a near-zero-cost enabler for a migration decision we have to make anyway, valuable only if the alternative is a delayed or high-risk auth cut-over — and worthless if we treat it as a maintained dependency.