User Bundle Laravel Package

Getting Started

First, the framework mismatch: mrgoodbytes8667/user-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/user-bundle.php. A Laravel developer’s "day-to-day leverage" is limited to two scenarios: (a) you’re maintaining a Symfony app alongside Laravel code, or (b) you’re shelling out to Symfony console commands from a Laravel job/command in a hybrid stack. If you’re purely Laravel, this is not a dependency you install.

Minimal steps if you do need it:

1. composer require mrgoodbytes8667/user-bundle
2. Register in config/bundles.php: MrGoodbytes\UserBundle\UserBundle::class => ['all' => true]
3. Ensure Doctrine ORM and a User entity are configured — the bundle’s commands operate against your existing user class, it does not ship its own persistence layer.
4. Run bin/console list user to discover the actual command surface (create, promote, demote, etc., in the FOSUserBundle spirit).

Where to look first: src/Command/ (the entire value of the package is CLI commands), then src/DependencyInjection/ for the config tree, and composer.json for the Symfony version constraints. The README is the secondary source; the commands are the primary.

First use case: creating a user non-interactively in a deploy script or CI step (bin/console user:create --email=... --password=...), or promoting an account to admin during provisioning. That’s the FOSUserBundle-era workflow this package is emulating.

Implementation Patterns

Command-driven user lifecycle. Treat the bundle as a provisioning tool, not a runtime library. The idiomatic pattern is to wrap the Symfony commands in deploy scripts, Ansible tasks, or CI pipeline steps rather than calling bundle services from application code. If you need programmatic access, inject the underlying command services or the user manager directly, but expect a thinner API than laravel/fortify or breeze.

Hybrid Laravel integration. If you must trigger these from Laravel, don’t try to autoload the bundle — it will fatal on missing Symfony contracts. Instead, use Symfony\Component\Process\Process or Laravel’s Process facade to run php /path/to/symfony-app/bin/console user:create ... and parse exit codes. Keep this behind an interface so the Symfony dependency is swappable.

Entity decoupling. The bundle expects to work against a user class you define. Map your entity in config/packages/doctrine.yaml and ensure the bundle’s config points at the correct class. This is the extension point: your entity, your repository, your password hasher. The bundle contributes commands and wiring, nothing more.

Extending commands. Rather than forking, subclass the provided commands and override configure()/execute(), or decorate them via services.yaml. This is the cleanest way to add fields (tenant ID, roles defaults) without touching vendor code.

CI/dev seed pattern. Use the commands in a Makefile or seeder equivalent: create admin, create fixture users, promote in test setup. This mirrors what php artisan db:seed does in Laravel, but with less control over ordering and idempotency — check whether commands are safe to re-run before putting them in scripts.

Gotchas and Tips

Adoption risk is the headline. Zero stars, zero dependents, and a single release in March 2024 means no community validation and no evidence anyone runs this in production. Audit the source before trusting it with auth-adjacent operations. Prefer symfony/console + your own commands if the bundle is doing anything you can’t verify.

Symfony version pinning. The composer.json constraints likely target a specific Symfony range (5.x/6.x). In a Laravel app, Symfony components are resolved by the framework — a hard requirement on symfony/framework-bundle will conflict or bloat your tree. Don’t install this into a Laravel composer.json unless you’ve verified the constraint graph.

Not a Laravel package. No ServiceProvider, no publishable config, no Eloquent integration, no artisan commands. Any tutorial or mental model from spatie/laravel-permission or similar will mislead you here. It is Doctrine + Symfony DI + Console.

Idempotency is unknown. Verify whether user:create fails or silently updates on duplicate email. Wrap invocations in your own existence check (bin/console user:find or a direct DB query) before relying on it in idempotent deploy scripts.

Debugging. Run commands with -vvv to surface DI and Doctrine errors, which are the most common failure mode (wrong entity class, unmapped field, missing password hasher). If a command isn’t registered, check bundle registration in bundles.php and clear the cache (bin/console cache:clear).

Extension points are thin. Beyond service decoration, command subclassing, and config-driven entity mapping, there’s little to hook into. If you need events (user created, role changed), you’ll likely add them yourself — don’t assume FOSUserBundle’s event system was ported.

Licensing is fine, maintenance is not. MIT is permissive, so forking into an internal namespace is viable. Given the activity level, plan for that fork as a contingency rather than assuming upstream fixes will arrive.