User Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (really: adopt vs. fork): This package is a thin, MIT-licensed command layer for user lifecycle operations (create user, promote/demote, reset password) modeled on FOSUserBundle's CLI. The real decision is not "buy vs. build" but "adopt a near-zero-traction dependency vs. vendor ~a few hundred lines of console commands." At this size, forking is cheap and removes the maintenance question entirely. The v0.6.0 release (annotations removed, code cleanup) confirms the codebase keeps shrinking toward its essentials — reinforcing that vendoring is a low-effort, low-regret path.
• Roadmap unblocking for admin/ops tooling: If user administration currently happens via manual DB edits, tinker-style scripts, or a half-built internal dashboard, these commands give you a defensible, repeatable interface for support and ops staff — a prerequisite for any SOC2-style access-control evidence or auditable provisioning workflow.
• Migration off FOSUserBundle: FOSUserBundle is effectively unmaintained. Teams standardizing on Symfony's native security/UserInterface still miss the ergonomic CLI. This package is a candidate to preserve familiar operator workflows during a migration without reimplementing them.
• Developer velocity and fixtures: Deterministic user creation for seeds, CI fixtures, and ephemeral preview environments. Low-risk, high-frequency use case — good candidate for a trial.
• Ecosystem-fit caveat that drives the decision: Despite the "Laravel/PHP package" framing, this is a Symfony bundle (FOSUserBundle lineage). If the product is genuinely Laravel, this is not a fit — the artisan equivalent (laravel/tinker scripts, custom commands, or Filament/Spark-style admin tooling) is the right comparison. Do not let the generic "PHP package" label smuggle a Symfony dependency into a Laravel roadmap.

When to Consider This Package

Adopt (or fork) when:

• You are on Symfony (5.4/6.x/7.x) and use the native security component, not Laravel.
• User admin is back-office, low blast radius, internal-only — not a customer-facing auth surface.
• You want FOSUserBundle-style CLI ergonomics with minimal code you'd have to write yourself.
• You have appetite to vendor/fork: still negligible community traction, and the project sits at v0.6.0 — pre-1.0 with no stability promise, so treat the public surface as movable.
• Note on v0.6.0: the release is pure housekeeping — annotation removal and code cleanup, no new features and no announced breaking changes. The annotation removal is a PHP 8 attributes modernization signal, not a capability change; if you were relying on annotation-based configuration anywhere in the bundle, diff before upgrading. It does not change the recommendation below.

Look elsewhere when:

• You are on Laravel. Wrong ecosystem; the framing is misleading. Use artisan custom commands or an admin panel package instead.
• Authentication/identity is core to your product. SSO/SAML/OIDC, MFA, tenant isolation, and password policy are out of scope for a command bundle — that's a platform decision, not a package decision.
• You need compliance guarantees: audit trails, immutable logs of privilege changes, approvals for role grants. This gives you the mutation, not the accountability layer.
• You cannot accept single-maintainer supply-chain risk. No meaningful dependents means no community CVE surface review and no forced-upgrade pressure; you will be the de facto maintainer at the first framework major.
• You need a supported SLA, vendor accountability, or a stable 1.x API contract — not available here at any price.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed set of administrative commands that lets support and ops manage user accounts safely without engineering involvement — no license spend, small surface area, and a contained failure mode if we abandon it. It accelerates internal tooling, not the product itself. Because it has essentially no adoption (no downstream dependents, single maintainer, still pre-1.0 at v0.6.0 after several point releases), we should treat it as internal tooling we own, not a vendor dependency we rely on.

To engineering: Symfony console commands for user create/promote/demote/password, FOSUserBundle-inspired, MIT, at v0.6.0. The latest release is maintenance-only (annotation removal, cleanup) — read it as "the maintainer is still touching the code," not as new capability or a sign of a support commitment. Recommend a time-boxed spike, then vendor the code into our repo rather than adding an unmaintained transitive dependency — it's small enough to own outright, eliminates abandonment risk, and keeps us free to extend toward our audit/role-grant requirements. Note the ecosystem check first: this is Symfony-only, so confirm scope before committing a sprint to it.