Enum Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on your domain modeling layer. This package is essentially a pre-PHP-8.1 abstraction for enumerated values with Symfony container wiring. The PM decision it informs is whether enum/status modeling is worth a dependency at all — and on any modern Laravel stack the answer is "build in-house with native PHP enums," not "buy."
• Legacy modernization sequencing. Where a product still runs PHP 7.4–8.0 (typically a Symfony 4/5 service, not Laravel), this package can be a low-cost stopgap to introduce typed enumerations without a language upgrade. That makes it a roadmap input for when to schedule the PHP 8.1+ migration rather than a permanent architectural choice.
• Dependency governance and vendor risk. With 12 stars, zero dependents, and a single maintainer, this is a textbook case for your dependency review board. It supports a policy decision ("we require ≥N maintainers / ≥X dependents for production dependencies") more than a feature decision.
• Domain vocabulary standardization. If a product has repeated status/state strings scattered across modules (order states, subscription tiers, approval flows), the underlying pattern — one canonical enum per concept — is a real product-quality lever. Adopt the pattern, in-house.
• Not a differentiator. Nothing here affects user-facing capability, time-to-market, or unit economics in a measurable way. It should never be prioritized against customer-facing roadmap items.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is Symfony-based and on PHP < 8.1, so native enum is unavailable.
• You need enumerations auto-registered in the Symfony DI container (the bundle's actual differentiator over the base yokai/enum library) — e.g., injecting enum sets into services or validating against them in forms.
• The scope is internal or low-blast-radius — admin tooling, back-office workflows, a bounded legacy module — where a single-maintainer dependency is tolerable.
• You are willing to pin the version and vendor the source as insurance.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle. There is no Laravel service provider, no Eloquent integration, no validation rule, no casting to model attributes. You would be adopting a foreign integration and writing the glue yourself.
• You are on PHP 8.1+. Native backed enums, enum_exists(), and match cover this completely, with zero dependency and full static analysis support. Laravel's casts and validation Rule::enum() handle persistence and request validation.
• You need API/serialization contracts. Nothing here addresses OpenAPI schema generation, JSON serialization, or translation of enum labels — the parts that actually cost engineering time.
• You need Eloquent casts, query scopes, or attribute casting — evaluate spatie/laravel-enum or archtechx/enums instead; both have materially larger ecosystems.
• You need database-level state machines or transition rules — enums model values, not allowed transitions; look at a state-machine package or explicit domain services.

How to Pitch It (Stakeholders)

For executives (one paragraph): A team member has surfaced yokai/enum-bundle, a small open-source library for defining enumerated value lists in Symfony applications. Our recommendation is do not adopt it. It solves a problem PHP itself solved in version 8.1, it has negligible community traction (12 stars, no downstream dependents, one maintainer), and it does not integrate with our Laravel stack. Adopting it would add a maintenance liability in exchange for no product capability. The only scenario worth revisiting is a legacy PHP 7.x Symfony service where it could save a few days of refactoring — and even there, the better investment is accelerating that service's PHP upgrade. Cost of adoption: near zero in license fees, non-trivial in long-term ownership. Cost of not adopting: none.

For engineering leads: Treat this as a pattern reference, not a dependency. The valuable output is the discipline of one canonical, typed enum per domain concept with a single source of truth for labels and validation — which we get for free from native PHP 8.1+ enums and Laravel's Rule::enum() plus attribute casting. If a legacy Symfony service on PHP < 8.1 genuinely needs container-registered enum sets, scope it to that service, pin the version, and record it in the dependency register with an explicit removal date tied to the PHP upgrade. Do not let it into shared libraries or anything customer-facing. If the underlying need is richer — Eloquent casting, query scopes, OpenAPI schemas — the correct evaluation set is spatie/laravel-enum or archtechx/enums, both of which carry real ecosystem weight and should be assessed against a build-in-house baseline.