- Is ops-talent/userbundle a Laravel package or a Symfony bundle?
- Despite being described as a Laravel package, ops-talent/userbundle is a Symfony bundle. The Bundle suffix, the DependencyInjection/ and Resources/config/ layout, and the bundle-alias configuration model are all Symfony conventions, while Laravel packages ship a service provider and a lowercase-hyphenated name. That means it cannot be registered or wired into a Laravel auth guard without essentially being rewritten.
- Can I use ops-talent/userbundle in a Laravel app?
- No. There is no Laravel service provider, no lowercase-hyphenated package name, and no Laravel-native registration for config, routes, or migrations. Installing it via Composer in a Laravel app would not make its authentication scaffolding usable by Laravel's guards. The realistic outcome is a rewrite that amounts to building a new package.
- Which Laravel versions does ops-talent/userbundle support?
- None. It targets Symfony, not Laravel, so there is no supported Laravel version range. Its actual constraints depend on the Symfony major version pinned in composer.json, which is unknown from the repository metadata alone.
- How do I install ops-talent/userbundle with Composer?
- You could run composer require ops-talent/userbundle, but that alone does not integrate it. In a Symfony app you would also need to register the bundle in bundles.php or AppKernel, configure the bundle alias, and satisfy its Doctrine, Security, and possibly FOSUserBundle dependencies. In a Laravel app, a successful Composer install does not produce a working integration.
- What Laravel packages should I use instead of ops-talent/userbundle for auth and roles?
- For Laravel, use first-party auth options such as Breeze, Fortify, Jetstream, or Sanctum, plus spatie/laravel-permission for roles and permissions. Those ship Laravel service providers, guards, migrations, and actively maintained security coverage. ops-talent/userbundle should be excluded from a Laravel bake-off on framework-fit grounds rather than quality grounds.
- Does ops-talent/userbundle include user models, migrations, and profile fields?
- The bundle's stated scope includes a user model, migrations, configurable profile fields, roles and permissions, and routes and views for registration, login, and account management. In practice those pieces are Symfony-style: a Doctrine entity rather than an Eloquent model, and Symfony Security rather than Laravel guards. Whether the bundle owns the entity and migrations or expects the host app to supply them is not stated and should be verified in composer.json and the bundle source.
- Does ops-talent/userbundle support PHP 8, Symfony 5, or Symfony 6?
- Very unlikely. A user bundle of this vintage almost certainly pins Symfony 2.8 or 3.x and constrains PHP accordingly, so PHP 8.x and Symfony 5 or 6 are expected hard blockers. Confirm with a Composer dependency-resolution dry run and composer why-not against your target application before planning anything else.
- Is ops-talent/userbundle maintained and safe to use in production?
- Treat it as high risk. It has 0 stars, 0 dependents, and a score of 0, which means no community review, no downstream users surfacing bugs, and no evidence anyone is patching it. Its domain is authentication and account handling, so any defect has a security blast radius, and there is no vendor to escalate to. Adoption is a formal risk-acceptance decision, not a code-quality one.
- How can I verify Composer compatibility before installing ops-talent/userbundle?
- Read composer.json first and confirm the PHP, Symfony, and FOSUserBundle constraints; that is a 15-minute gate that can invalidate the evaluation outright. Then run a dependency-resolution dry run and composer why-not against your application's composer.json. Also check the license, the last commit date, and any open issues or pull requests.
- How do I replace ops-talent/userbundle if I am already using it, or migrate an existing Symfony app?
- If you are maintaining a legacy Symfony app already on FOSUserBundle, vendor or fork the bundle into your monorepo, pin the fork, and reassign ownership to your team as first-party code. For anything else, do not adopt it: use Symfony's native Security bundle with MakerBundle to build a bespoke user entity, which takes days and removes the fork liability. If you are on Laravel instead, migrate to Breeze, Fortify, or Jetstream with spatie/laravel-permission.