Enum Bundle Laravel Package

Product Decisions This Supports

• Standardize-or-not on enum conventions. This bundle is fundamentally a convention layer for how enums surface in the product: DI configuration, form choices, validation messages, serialization, Twig rendering, and Doctrine persistence. Evaluating it forces the real decision — do we standardize enum handling now, or keep letting it be ad hoc per feature?
• Build vs. buy vs. use framework core. PHP 8.1 backed enums plus Symfony core (EnumType in 6.2+, BackedEnumNormalizer in 6.1+, enum-aware Choice validation, Doctrine custom types) cover roughly 80% of what a bundle like this offers. The decision is whether the remaining glue justifies an external dependency.
• Platform baseline / roadmap sequencing. Adoption implies a PHP 8.1+ and Symfony-version constraint anchored to a 2022 release. That's not a library pick — it's a decision about how long we stay on that Symfony line and what blocks our next major upgrade.
• UX and API contract decisions. Human-readable labels vs. raw enum values in dropdowns and API payloads; label i18n; choice ordering and grouping; admin filter behavior; what happens to clients when a case is added or removed.
• Persistence and migration decisions. Store name vs. value vs. int; migration playbook when enum cases change; backward compatibility guarantees for consumers of enum-bearing fields.
• Own-vs-depend risk posture. 11 stars, 0 dependents, last release October 2022 — this is a candidate for "vendor the pattern, not the package," which is itself a build-vs-buy call worth making explicitly.

When to Consider This Package

Consider it when:

• You are on Symfony (this is a Symfony bundle, not a Laravel package) on PHP 8.1+, and enums are pervasive across forms, validation, DI, serialization, and Doctrine.
• You are on Symfony below 6.2 and don't yet have EnumType / enum-aware Choice, or upgrading is not on the near-term roadmap.
• A small team wants instant, opinionated conventions instead of writing the glue themselves, and the appetite for ~200 lines of in-house code is zero.
• The blast radius is internal tooling or back-office surfaces where a stale dependency is survivable.
• You specifically want bundle-level configuration for enum metadata (labels, groups, registration) rather than per-enum boilerplate.

Look elsewhere when:

• You are on Laravel. Hard stop — a Symfony bundle won't integrate, and Laravel's native enum casts plus Rule::enum validation already solve this.
• Zero dependents + no release since 2022. No downstream validation, no evidence of fitness, likely abandonment. If you need maintenance or LTS guarantees, no.
• You are on Symfony 6.2+/7 and core already covers the majority of the surface area — build the thin layer in-house.
• Supply chain is reviewed. Single maintainer, unmaintained, and low adoption is a non-starter in a compliance-gated environment.
• Your enum usage is purely domain-level with no forms, DI, or serialization concerns — the bundle adds nothing.

How to Pitch It (Stakeholders)

For executives: Low cost and low commitment, but this is a small, effectively unmaintained Symfony bundle — 11 stars, zero dependents, and no release in roughly three years. The recommendation is a timeboxed spike, not an adoption. The durable value here isn't the package; it's the convention it represents for enums across forms, APIs, and the database. We can get most of that from PHP 8.1 enums plus Symfony core, so the strategic ask is "let's standardize how we handle enums," not "let's buy this library." Also worth flagging early: it's Symfony-only, so it is out of scope if our stack is Laravel.

For engineering: It's a thin Symfony integration layer that wires enum metadata into DI, forms, validation, Twig, and Doctrine. The question is whether it saves more glue code than the risk it adds — it pins us to a 2022 PHP/Symfony matrix, has a single maintainer, and has no dependents to demonstrate fitness. Proposed path: a one-to-two day spike against our actual enum usage, measuring glue code saved versus the core alternatives. If we adopt, fork or pin the version and budget for owning it. If we don't, capture the resulting pattern in an internal package so we own the upgrade path and the convention survives regardless of the vendor.