Enum Bundle Laravel Package

Product Decisions This Supports

A "build vs. buy vs. use the language" decision for typed enumerations. The core product question this package informs is whether our domain constants (order status, subscription state, role, feature flags, payment method) should be modeled with a third-party library, a Symfony bundle, or native PHP 8.1 enum. That decision touches every service that owns a state machine.

A legacy platform-retention decision. The package is explicitly a Symfony2 bundle, not a framework-agnostic library. Its existence on a Laravel roadmap is itself a signal: it supports the decision of whether to keep servicing a legacy Symfony 2.x surface or fund a migration. Framed this way, the package is a migration-cost input, not a feature dependency.

A dependency-policy decision. 31 stars, 0 dependents, and a bundle-era scope means the realistic roadmap question is not "how do we use this?" but "what is our threshold for adopting an unmaintained dependency?" The answer becomes a reusable policy for the next twenty packages the team evaluates.

Concrete use cases it would theoretically serve — enum-typed entity fields, form choice types, Doctrine column mapping, and validation constraint integration in a Symfony 2 app. In a Laravel codebase, none of that wiring transfers: bundles are not auto-discovered by Laravel, so a service provider, config publishing, and manual registration would all be net-new work.

Not supported: any roadmap item assuming active maintenance, security patching, or a community to lean on during an incident.

When to Consider This Package

Adopt only under a narrow, converging set of conditions:

• You are maintaining a live Symfony 2.x application that already uses the bundle system and cannot move to Symfony 4+ or PHP 8.1 in the current planning horizon.
• You are on PHP 7.x and need enum semantics with Symfony container/Doctrine integration that hand-rolled constants would not give you cheaply.
• The enum surface is small and stable — a handful of status fields, not a domain modeling strategy.
• You have accepted the risk of vendor ownership: read the source, vendor it if necessary, and treat it as internal code you happen to have downloaded.

Look elsewhere — or build — when:

• You are on Laravel. This is the decisive criterion. A Symfony bundle is the wrong artifact type; the integration work exceeds the value, and the framework boundary makes contributions or bug fixes unlikely to be upstreamed in a form that helps you.
• You are on PHP 8.1+. Native enum with backed cases and interfaces covers the overwhelming majority of use cases with zero dependency risk. This is the default recommendation.
• You need active maintenance. Zero dependents and a Symfony2-era scope indicate a dormant project; there is no evident path to a security patch or a response to a filed issue.
• You need richer behavior than typed constants — comparisons, attribute hydration, or framework-agnostic usage. Actively maintained alternatives such as myclabs/php-enum or spatie/enum fit a Laravel stack far better and carry a support community.
• The decision is load-bearing. For a core domain concept, the dependency risk is not worth the saved keystrokes.

How to Pitch It (Stakeholders)

To executives: We evaluated a candidate library for typed enumerations and are recommending against adoption. It is a Symfony 2-era bundle with 31 GitHub stars, no downstream dependents, and no sign of active maintenance. Its apparent "opportunity" score reflects a gap in the ecosystem, not readiness of this artifact. Meanwhile, PHP 8.1 ships native enums that cover the same need with zero third-party exposure. Buying here would trade a small amount of typing for an indefinite maintenance liability — the classic bad trade. Recommendation: no spend, no integration, adopt native enums as the standard.

To engineering: Treat this as a reference implementation, not a dependency. Read it for one hour if you want a pattern for enum-aware Symfony 2 forms and Doctrine mapping, then close the tab. The bundle's mechanism — compiler-pass registration of enum types into the container — has no analogue in Laravel's service container, so porting cost is real and the benefit is small. For anything new, use native backed enums; where you need Laravel-specific behavior like validation rules, casts, or labels, use spatie/enum. If we still own a Symfony 2 service, that is a migration conversation, not a library-selection one, and this package should be logged as a migration-debt marker rather than a proposed addition.