Enum Bundle Laravel Package

Product Decisions This Supports

• Standardizing a finite-value convention — status, currency, type, role. The package supplies the Symfony wiring (service registration, form EnumType, Doctrine DBAL types) so a single enum convention can be enforced across the codebase instead of ad-hoc constants and magic strings. That is a codebase-hygiene decision the package makes cheaper, not a decision the package makes for you.
• Build vs. buy for plumbing. The package is thin glue around lamoda/php-enum. If the need is "enums in Symfony forms and Doctrine without hand-writing a form type and DBAL type per enum," buying (MIT, free) is cheaper than building and maintaining. If the need includes OpenAPI/schema generation, admin UI generation, or translated labels, you will build on top regardless — so this dependency is a partial down payment, not a solution.
• Stack decision input: Symfony vs. Laravel. This is a Symfony bundle. No service provider, no Eloquent casts, no publishable config. In a Laravel codebase only the framework-agnostic lamoda/php-enum library applies and you write your own casts. Flag it as an input to framework choice, not just a composer decision.
• Supported-version floor (updated by 1.6). Release 1.6 adds Symfony 6 support, so the bundle is no longer disqualified purely on version constraints for Symfony 5/6 shops. This widens the addressable stack but does not change the underlying trade: Symfony 6 is effectively a PHP 8.0.2+/8.1 stack, i.e. exactly where native backed enums and Symfony's built-in enum support already cover most of this package's surface.
• Roadmap: bridge or permanent? PHP 8.1 native backed enums plus Symfony's built-in enum support (form type, Doctrine type, validation) cover most of this package's surface. The PM decision to force now: is this a bridge dependency with a removal date, or a standing convention? Recommend an explicit bridge framing on the tech radar.
• Velocity/estimation input. Adoption replaces per-enum boilerplate with one class plus a config entry. Worth a small, measurable reduction in CRUD story points — never a reason to adopt on its own.
• Best-fit use cases: internal tools and admin panels, legacy Symfony upgrades where lamoda/php-enum is already in the tree, small services with many small enums and a need for consistent form rendering — now including Symfony 6 services that have not yet migrated to native enums.

When to Consider This Package

Adopt only when all of these hold:

• The application is Symfony (5.x or 6.x as of 1.6) — the bundle's entire value is DI/form/Doctrine integration; outside Symfony it is dead weight.
• You need forms and persistence for enums and want that wiring without custom types per enum.
• Either PHP < 8.1, an existing lamoda/php-enum investment, a live Symfony 5 codebase not yet on native enums, or a deliberate preference for that library's API over native enums.
• Low bus-factor risk is acceptable: internal or non-critical services, or you are willing to vendor/fork.

Look elsewhere when:

• PHP 8.1+ on current Symfony — native enums plus built-in support is the lower-risk default; adoption adds a dependency for shrinking benefit. Note 1.6 does not change this: Symfony 6 support makes the package installable on a stack that already has the native alternative.
• Laravel — no bundle support; use native enums with Eloquent casts, or a Laravel-specific enum package.
• Dependency risk matters — very small ecosystem footprint (10 stars, 0 dependents) and a narrow release history. Release 1.6 is a positive maintenance signal (the project is still being touched, and it is now installable on current Symfony), but a single compatibility bump is not evidence of a support commitment. Avoid for long-lived, high-traffic, or audited products.
• You need OpenAPI generation, admin UI generation, or translated labels — those are out of scope; budget the extra build.
• You need bitmask flags, enum collections, or heavy comparison logic — different problem shape.

Decision rule: if Symfony on PHP 8.1+ native enums covers your cases, the correct PM answer is still "no new dependency." 1.6 removes a version blocker, not the reason to prefer native enums. Adopt only where boilerplate savings are concrete and the codebase is already committed to the underlying library.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed utility that removes repetitive code from how we model fixed lists of values — order status, currency, user role. The new 1.6 release adds Symfony 6 compatibility, which means it is not frozen on an old framework version and we can run it on current Symfony services. Cost is near zero and it is easy to remove. But it remains a small, low-adoption library (10 stars, no dependents) and 1.6 is a compatibility bump rather than a sign of active roadmap investment, so we treat it as a tactical convenience with a planned exit to PHP's native enums, not a platform commitment. Recommendation: approve for Symfony services as a bridge dependency; revisit at the next major PHP/Symfony upgrade.

To engineering: It is glue, not a framework. The bundle registers enum services, provides a form type, Doctrine DBAL types, and validation so you stop hand-writing a type class per enum. Release 1.6 is a one-line change — Symfony 6 is now allowed by the constraint — so nothing in our code changes and there are no breaking changes or deprecations to plan around. Two caveats, stated plainly: (1) it is Symfony-only — Laravel gets nothing but the base lamoda/php-enum library and hand-written casts; (2) Symfony 6 is a PHP 8.1-era stack, so native backed enums plus Symfony's built-in support cover most of this, meaning adoption is a conscious trade of one thinly-maintained dependency for less boilerplate. Zero dependents means no community safety net — vendor or fork it before it goes anywhere critical.

The ask: approve conditional use in Symfony 5/6 services with a documented migration path to native enums; do not approve as a standard for new Laravel work, and do not treat the 1.6 compatibility bump as justification to expand scope.