- What is nucleos/fos-user-bundle-polyfill and what does it do?
- It is a compatibility polyfill that supplies legacy FOSUserBundle model interfaces and class names so existing code and third-party bundles keep working while you migrate to NucleosUserBundle. It is a lightweight bridge, not a full replacement for FOSUserBundle behavior. Its scope is limited to satisfying type hints and class references, so it does not provide routing, persistence, password hashing, or user-provider logic.
- Does this package work with Laravel applications?
- Only in a narrow, temporary sense. The package is not Laravel-native: it ships no service provider, no auth guards, no Eloquent integration, and no runtime wiring. It is useful only if your Laravel or PHP codebase still type-hints against legacy FOSUserBundle model interfaces during a migration. Do not introduce it into greenfield Laravel auth, user, or identity domains.
- Is this a replacement for FOSUserBundle or Laravel's authentication system?
- No. It only provides base model interfaces and class names, so satisfying a type hint does not deliver any actual FOSUserBundle or Laravel auth behavior. Treat it as an anti-corruption shim that buys you time to replace legacy contracts with app-owned interfaces or Laravel-native contracts. Real authentication, user providers, and password hashing must come from your application or Laravel itself.
- How do I install nucleos/fos-user-bundle-polyfill with Composer?
- Install it with composer require nucleos/fos-user-bundle-polyfill, ideally in an isolated branch first. Verify that the package's PHP and Composer constraints match your target runtime before merging. Because there is no framework integration to configure, validation is mostly about autoloading, namespace collisions, and static analysis rather than runtime setup.
- Do I need to register a service provider or configure anything?
- No. The package has no Laravel service provider and no configuration files to publish, because it only provides interfaces and class names. Integration is purely through Composer autoloading and the legacy type hints your code already uses. That also means installing it will not change any application behavior by itself.
- Which PHP and Laravel versions are supported?
- The package was last released on 2020-01-11 and is archived, so there is no declared support for modern Laravel or PHP releases. Check the composer.json constraints against your exact PHP runtime before adopting it, and expect potential incompatibility with newer PHP versions. If you must keep it, vendor or fork it and pin the constraints deliberately.
- Is the package still maintained and safe for production?
- It is archived with no maintainer-backed fixes, no security-response commitment, and almost no ecosystem validation (roughly 2 stars and 0 dependents). That makes it effectively self-supported: your team owns compatibility, patching, and any security review. Use it only as a controlled, time-boxed compatibility experiment, never as a strategic user-management dependency.
- How do I migrate from FOSUserBundle to NucleosUserBundle safely?
- Start by inventorying every reference to FOSUserBundle model interfaces, type hints, and serialized assumptions in your codebase. Install the polyfill behind an isolated compatibility layer or adapter rather than referencing it directly in domain code. Map legacy user and group interfaces to application-owned contracts, run contract tests, and then delete the polyfill and its adapters once the legacy dependency is removed.
- How can I test that the polyfill matches the legacy FOSUserBundle contract I depend on?
- Run static analysis against the exact legacy FOSUserBundle version you are emulating, and add targeted contract tests that assert the interfaces and method signatures your code relies on. Confirm namespace and autoload behavior alongside your other legacy packages to catch collisions. Also check whether any installed dependency already provides overlapping FOSUserBundle classes or interfaces.
- What alternatives exist to using this polyfill?
- The preferred alternatives are app-owned interfaces with adapters, an anti-corruption layer around legacy user models, or Laravel-native contracts such as Illuminate\Contracts\Auth. You can also migrate directly to NucleosUserBundle without the intermediate polyfill. If long-term compatibility is unavoidable, vendor or fork the polyfill under explicit ownership with a documented patch policy instead of relying on the archived upstream package.