Auth Bundle Laravel Package

Getting Started

First, the framework reality check: despite the prompt framing you as a Laravel developer, netbull/auth-bundle is a Symfony bundle (the Bundle suffix and netbull namespace follow Symfony conventions). You cannot composer require it into a Laravel app and expect it to boot. Treat this assessment as "what would I need to know if I were porting these auth concepts into a Laravel app, or if I were the Symfony developer on a team that adopted it."

If you actually are working in Symfony:

1. composer require netbull/auth-bundle — but pin the version. The last release (v7.0.5, 2026-05-29) is again forward-dated depending on when you read this, and with 0 stars and 0 dependents you are the canary. v7.0.5 is a patch that only "added deprecation" — see Gotchas, because deprecation notices are an early signal that API surface is shifting.
2. Register the bundle in config/bundles.php (Symfony Flex should do this if the bundle ships a recipe, which is unlikely at this maturity — expect to add it manually).
3. Publish/inspect the bundle's DependencyInjection/Configuration.php before writing any YAML. That class is the authoritative source of truth for config keys — the README is likely stale or thin. Look here first, not at the README.
4. Check Resources/config/ (or config/) for the service definitions and Routing/ or Controller/ for exposed endpoints. Your first real use case is almost certainly: wire the bundle's user provider and firewall authenticator into config/packages/security.yaml, then hit the login route with a test user.

For a Laravel developer the "first use case" is really a research spike: read the bundle's controllers and event listeners, map each to a Laravel analogue (Guard, Auth::attempt, Sanctum/Passport, Password::sendResetLink), and decide whether to reimplement rather than depend.

Implementation Patterns

• Firewall-first integration (Symfony). Auth bundles live or die by how they slot into security.yaml. Expect a custom UserProvider, an Authenticator (Symfony 5.3+ authenticator-based security) or a legacy guard, and a firewall entry. Configure the firewall, then the provider, then the bundle's own options — order matters because the bundle usually reads security.firewalls.* at container compile time.
• Event-driven extension. Typical auth bundles dispatch events (LoginEvent, RegistrationEvent, PasswordResetRequestEvent) via EventDispatcherInterface. The idiomatic pattern is to subscribe to those rather than override controllers — override controllers only as a last resort, because they change between minor versions.
• Doctrine entity assumptions. Most bundles ship a base User model or interface. Extend it in src/Entity/User.php, register the mapping, and run migrations. Do not reuse the bundle's own entity table blindly in production; copy the schema into your app's migrations so you control it.
• Token workflows. If it issues JWTs/refresh tokens, treat token TTL, rotation, and revocation as your responsibility. Look for a token manager service and wrap it behind your own service so you can swap it out.
• Laravel translation of the same patterns (if porting): map bundle "authenticator" → Laravel Guard/middleware; "event subscribers" → EventServiceProvider listeners; "user provider" → EloquentUserProvider; "token manager" → Sanctum personal access tokens or tymon/jwt-auth. You'll get 90% of the value in a fraction of the abstraction.

Gotchas and Tips

• AGPL-3.0 is the headline risk. AGPL is copyleft over the network. If you expose a service built on this bundle, the AGPL arguably obliges you to release source. For most commercial Laravel/Symfony products this is a non-starter — confirm with legal before you build on it. This alone likely explains the low adoption scores.
• Zero dependents / zero stars = no safety net. There are no StackOverflow answers, no blog posts, no third-party tutorials. Every bug is yours to debug. Budget for reading vendor/netbull/auth-bundle source directly; it will be your primary documentation.
• Framework mismatch. As a Laravel developer, do not try to bridge it. There is no Laravel service provider, no facade, no published config. If you want the functionality, use Sanctum/Passport/Breeze/Fortify instead — all first-party, MIT-licensed, and well-documented.
• v7.0.5 is a deprecation-only patch — treat it as a warning shot. The sole change in the new release is "added deprecation" (commit 7c5c7a8), with no feature or behavioural notes. On a package this immature that usually means a config key, service ID, or method is being phased out ahead of a rename/removal — exactly the churn surface you're exposed to. Read the actual deprecation trigger in the source (grep for E_USER_DEPRECATED / trigger_deprecation / @deprecated) before you write against anything new, and don't assume the deprecation is cosmetic just because it shipped as a patch bump.
• Config key churn. With a single maintainer and a fast-dated release, config keys and service IDs can shift between minors. Pin the exact version in composer.json ("netbull/auth-bundle": "7.0.5") and read the changelog and the diff before every bump — a deprecation-only patch like this one can still remove the very hook you relied on in a subsequent minor.
• Debugging tip: when authentication silently fails, dump the compiled container — bin/console debug:container --tag=security.authenticator and bin/console debug:config netbull_auth (name may differ; get the extension alias from DependencyInjection/*Extension.php). Nine times out of ten the bundle config is loaded but the firewall isn't pointing at the authenticator. If v7.0.5's deprecation is config-related, debug:config will warn you if you're still using the deprecated path.
• Extension points to prefer: event subscribers, custom user provider, and decorating the token manager service. Avoid subclassing bundle controllers — they are the least stable surface. If v7.0.5 deprecated a method you override, you'll feel it on the next minor; prefer decoration so you can adapt in one place.
• Testing: use Symfony's KernelTestCase/WebTestCase and hit the login route end-to-end. Don't unit-test the bundle internals; you'll be testing their code, not yours, and it will break on upgrade. After bumping to v7.0.5, run the suite with deprecation reporting enabled (SYMFONY_DEPRECATIONS_HELPER=max[self]=0 or weak) so the new deprecation shows up as a failing assertion rather than a log line you never read.
• License escape hatch: if you only need the ideas, read the source (AGPL permits reading) and reimplement the auth flow in your own MIT/Laravel codebase. Given 0 dependents, an AGPL license, and a maintainer now shipping deprecations on a package with no downstream canaries, that is very likely the pragmatic path.