User Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — before anything else, confirm your project is Symfony 4/5 (the 2020 release date points at Symfony 4.4/5.x). A Laravel app can only use this by manually wiring Symfony's Security, Doctrine, and HttpKernel components, which is almost never worth it.

Minimal steps:

1. composer require soft-passio/user-bundle
2. Register SoftPassio\UserBundle\UserBundle in config/bundles.php (Symfony 4+ flexible recipe) or AppKernel::registerBundles().
3. Look first at the bundle's DependencyInjection/Configuration.php and Resources/config/ — the README is thin, and the real contract is the service definitions and the Configuration tree.
4. Inspect the Model/ or Entity/ directory to see whether users are shipped as a concrete entity or as an abstract base class / traits you're expected to extend.
5. Generate a migration if the bundle ships Doctrine mappings: bin/console doctrine:migrations:diff.
6. Wire the firewall provider and password_encoder in config/packages/security.yaml to whatever the bundle's user class is.

First use case: swap the bundle's user entity into your existing security.yaml provider, run migrations, then exercise registration + login — that path proves the Doctrine mapping, the encoder, and the provider all line up.

Implementation Patterns

Extend, don't fight, the entity. Symfony user bundles almost always expose an AbstractUser or a User class with protected setters. The idiomatic move is to create App\Entity\User extends SoftPassio\...\User in your own src/Entity/, add your domain fields, and point doctrine.orm at your class. Overriding via inheritance keeps bundle upgrades non-destructive.

Provider + firewall wiring. Register a entity provider pointing at your user class and a form-login firewall using the bundle's login route. If the bundle ships its own UserProvider, prefer that only if it adds behavior (e.g. email-based lookup) — otherwise Symfony's built-in entity provider is simpler and better documented.

Events over patching. If the bundle dispatches lifecycle events (registration, password change), hook them with a small EventSubscriber in src/EventSubscriber/. This is the clean place to add welcome emails, audit logs, or role seeding without touching vendor code.

Form types as the integration seam. Bundles of this vintage ship RegistrationFormType / ChangePasswordFormType under Form/. Reuse them via createForm(BundleFormType::class, $user) and add your extra fields through FormEvents::POST_SET_DATA rather than copying the class.

Service decoration. Any service in the bundle can be replaced by declaring a class with the same ID under decorates: in services.yaml. This is the supported way to change validation, token generation, or mailer behavior.

Templates. Copy the bundle's Resources/views/ into templates/bundles/UserBundle/ to override Twig templates per Symfony's bundle override conventions — no bundle forking required.

Gotchas and Tips

• This is effectively abandoned. Zero stars, zero dependents, and the last release is 2020-06-12. Treat it as a reference implementation to read, not a dependency to trust with authentication. Auth code that never gets security patches is a liability; consider Symfony's own MakerBundle user scaffolding instead.
• PHP/Symfony version drift. A June 2020 bundle will likely declare php: ^7.2 and Symfony 4.4/5.0 constraints. Composer will refuse to install it on PHP 8.2+ or Symfony 6/7 without --ignore-platform-reqs, and even then the deprecated PasswordEncoderInterface and older security.yaml syntax may break.
• Doctrine mapping conflicts. If the bundle ships an @ORM\Entity on its own class, extending it and mapping the subclass can trigger "duplicate mapping" or "association refers to unmapped class." Check whether the base class is @MappedSuperclass — that's the tell for "extend me."
• Password hashing API mismatch. Post-2020 Symfony moved from encoder to password_hasher and from getSalt() to SaltedPasswordHasher. If the bundle's User still implements getSalt(), you must either return null or migrate the encoder config explicitly.
• Migration ordering. The bundle's migrations, if shipped under Resources/migrations/, need to run before any of your own FK-dependent tables. Check the version prefix numbers; collisions with your migrations/ namespace are common.
• Debugging tip: when routes or services silently don't appear, run bin/console debug:container --tag=... and bin/console debug:router | grep user. Bundles of this age sometimes use XML service definitions that fail to autoload tags.
• Extension points to verify before adopting: does it dispatch a UserEvent/*Events class? Does it expose a UserManager interface? Without either, every customization becomes a fork — a strong reason to skip it.
• For a Laravel developer specifically: there is no Laravel equivalent here. If you're evaluating for a Laravel project, stop — use laravel/breeze or laravel/fortify, which cover the same ground with maintained code and native Eloquent integration.