User Bundle Laravel Package

Getting Started

Before writing a single line against this package, confirm what it actually is. tunet/user-bundle follows Symfony bundle naming (Tunet\UserBundle) and lives on GitLab rather than Packagist, which usually means one of three things: an internal company bundle, a learning/experimental project, or an abandoned one. The lack of stars, dependents, and a meaningful description means you are the first real consumer — treat the source as the documentation.

First steps:

1. Clone and read composer.json first. This tells you the required PHP version, whether it targets symfony/framework-bundle (Symfony) or illuminate/support (Laravel), and what it depends on (Doctrine, Security, FOSUserBundle, etc.).

   git clone https://gitlab.com/tunet000/user-bundle.git
   cd user-bundle
   cat composer.json
   

2. Check the bundle class and DI extension. For a Symfony bundle, look for TunetUserBundle.php and DependencyInjection/TunetUserExtension.php plus Configuration.php. The config tree in Configuration.php is the real API surface — it lists every option you can set under tunet_user: in config/packages/.

3. Locate the entities/models. Look under Entity/, Model/, or Document/. If there is a User entity with #[ORM\Entity], you'll need Doctrine migrations. If the entity is @MappedSuperclass, you're expected to extend it in your app.

4. Add it as a VCS repository if it isn't on Packagist:

   {
     "repositories": [
       { "type": "vcs", "url": "https://gitlab.com/tunet000/user-bundle.git" }
     ]
   }
   

   Then composer require tunet/user-bundle:dev-main (check the default branch name — it may be master).

5. Register the bundle (Symfony) in config/bundles.php:

   Tunet\UserBundle\TunetUserBundle::class => ['all' => true],
   

First use case: get one user persisted and authenticated end-to-end. Create the entity/migration, seed a user via a console command or fixture, wire the security provider, and log in. If that path isn't obvious from the README, that itself is your assessment signal.

Framework warning: if you're a Laravel developer, stop and reconsider. A Symfony bundle will not drop into a Laravel app — its service providers assume the Symfony container, its entities assume Doctrine ORM, and its security integration assumes symfony/security-bundle. If you need this in Laravel, you're looking at either porting the domain logic (entities, password hashing, roles) into Eloquent models or running it as a separate Symfony service. Confirm the target framework before investing time.

Implementation Patterns

Once you've confirmed it's a Symfony bundle, these are the patterns you'll actually live in day-to-day.

Configuration-first setup. Everything the bundle exposes should be driven through config/packages/tunet_user.yaml. Read Configuration.php and mirror the tree:

# config/packages/tunet_user.yaml
tunet_user:
  # copy keys directly from Configuration.php — do not guess
  user_class: App\Entity\User

Extending vs. using the shipped entity. The critical decision. Check whether the bundle's User is a concrete entity or a MappedSuperclass:

// If MappedSuperclass, extend it in your app:
namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;
use Tunet\UserBundle\Entity\User as BaseUser;

#[ORM\Entity]
#[ORM\Table(name: 'app_user')]
class User extends BaseUser
{
    // Add your app-specific fields here
}

If it's a concrete #[ORM\Entity], you have two options: use it as-is (simplest, but couples your schema to the bundle) or fork/copy it into your app. For anything long-lived, prefer copying the entity into your own App\Entity namespace so future bundle updates can't silently change your schema.

Security wiring. Point Symfony's provider at the bundle's user class:

# config/packages/security.yaml
security:
  providers:
    app_user_provider:
      entity:
        class: App\Entity\User
        property: email
  firewalls:
    main:
      provider: app_user_provider
      form_login:
        login_path: app_login
        check_path: app_login

Verify which password encoder the bundle expects — auto, bcrypt, or a custom PasswordHasher. Mismatches here produce the classic "Invalid credentials" on correct passwords.

Event-driven extension. Well-built user bundles dispatch lifecycle events (UserCreatedEvent, UserRegisteredEvent, PasswordResetRequestedEvent). Grep for EventDispatcherInterface or dispatch( in the source. If present, subscribe to these rather than overriding services:

class UserCreatedListener
{
    public function __invoke(UserCreatedEvent $event): void
    {
        // send welcome mail, provision tenant, etc.
    }
}

Overriding services. If the bundle dispatches no events, override its services in config/services.yaml using the bundle's service ID:

services:
  tunet_user.registration_service:
    class: App\Service\CustomRegistrationService
    arguments: ['@doctrine.orm.entity_manager', '@event_dispatcher']

Get service IDs from Resources/config/services.yaml (or config/services.yaml) inside the bundle — never guess them.

Integrating with the rest of your app. Keep your domain logic out of the bundle. Treat it as infrastructure: your controllers and application services should depend on your own UserRepository interface, with the bundle's entity as an implementation detail. This makes the bundle replaceable — important given its maturity level.

If you are a Laravel developer forced to integrate this, the practical pattern is anti-corruption layer: consume the bundle's concepts (User, roles, password hashing) and re-expose them as Eloquent models and Laravel guards. Don't try to mount the Symfony container inside Laravel.

Gotchas and Tips

The supply-chain and maintenance risk is the headline gotcha. Zero stars, zero dependents, no description, GitLab-hosted. That is not automatically bad (plenty of solid internal bundles look like this), but it means: no community to catch bugs, no Stack Overflow answers, and no guarantee of security patches. Pin to a specific commit SHA rather than a branch:

"tunet/user-bundle": "dev-main#a1b2c3d4e5f6..."

Audit the auth code before shipping. User bundles handle password hashing, registration tokens, password reset flows, and role assignment. Review, at minimum: how passwords are hashed (never md5/sha1), whether reset tokens are single-use and expiring, whether role escalation is possible via mass assignment, and whether the registration form allows setting arbitrary roles. If these look weak, don't use the bundle's flows — borrow only the entity and write your own controllers.

Configuration quirks to expect:

• Bundle config keys are prefixed by the bundle's alias, derived from the extension class name (TunetUserExtension → tunet_user:). Confirm in getAlias().
• Symfony's config tree silently ignores unknown keys only if ignoreExtraKeys is set; otherwise you'll get an InvalidConfigurationException. Read Configuration.php before writing YAML.
• Some bundles require you to import routes manually: tunet_user: in config/routes.yaml. Check Resources/config/routing.yaml.

Missing migrations. If the bundle ships an entity but no migrations, you must generate them yourself:

php bin/console make:migration
php bin/console doctrine:migrations:migrate

Review the generated SQL — bundles with @MappedSuperclass entities sometimes omit indexes on email or username, which you'll want to add.

Debugging tips:

• php bin/console debug:container --tag=... and debug:config tunet_user are your fastest ways to see what the bundle actually registered.
• If services aren't found, check that the bundle is in config/bundles.php and that composer dump-autoload has run after a VCS install.
• Enable framework: { php_errors: { log: true } } and watch var/log/dev.log — bundle errors often surface as container compilation failures with unhelpful messages.
• Use php bin/console lint:container to catch DI wiring problems before runtime.

Extension points to prefer, in order: events → service decoration → service override → forking. Each step down the list increases your maintenance burden when (if) the bundle is updated.

Have an exit plan. Given the maturity signals, write your integration so the bundle can be removed in a day: keep your User entity in App\Entity, depend on your own repository interfaces, and avoid leaking bundle classes into controllers. If the bundle proves unmaintained, forking the ~few files you actually use into App\ is often cheaper than living with the dependency.

Composer version constraints. If the bundle declares a narrow constraint like "symfony/framework-bundle": "^5.0" and you're on Symfony 7, Composer will refuse to install or you'll need --ignore-platform-reqs (don't). In that case, evaluate whether the code is worth backporting rather than forcing it.