Enumeration Laravel Package

Product Decisions This Supports

• Single source of truth for finite value sets. The package lets a domain concept (order status, refund reason, role, plan tier, event type) live as one PHP class with constants plus helpers to render it as a keyed array or select list. This directly supports any feature spec that reads "dropdown of allowed values," because the UI options, the validation rule, and the stored value all derive from the same declaration.
• Build vs. buy for "enum plumbing." The decision this package informs is whether to adopt a third-party abstraction or implement the pattern natively. On PHP 8.1+ the answer is almost always native enum; this package is the option to weigh only where you're held back by an older runtime or a Laravel version that predates first-class enum validation.
• Roadmap input on legacy modernization. The most useful PM artifact here is a migration ticket: inventory where an Enum-style abstraction is used, then scope the conversion to native backed enums with Rule::enum(). Adoption decisions on this package are really decisions about deferring that migration.
• Feature-level risk assessment. Because the package is presented as a select dropdown source, low-quality or unmaintained enum layers become a UX and data-integrity risk (stale options, drifted constants, inconsistent validation), not just a code-quality nit. That's a product-facing concern worth tracking.
• Reusable form/validation patterns. If a team standardizes on an enum abstraction, it touches every create/edit form and every API payload that accepts a constrained value. That has real leverage on delivery speed for CRUD-heavy roadmaps, which is why the build-vs-buy call is worth making once, deliberately, rather than per feature.

When to Consider This Package

Consider it only under a narrow set of conditions:

• Legacy runtime. The application is on PHP 8.0 or earlier, or a Laravel version without built-in enum casting and enum validation, so native enums are not available in practice.
• Existing dependency. The codebase already uses eloquent/enumeration (the package this forks from) and you need a maintained continuation rather than a rewrite. In that case the fork is a stopgap, not a new commitment.
• Modest, well-bounded need. You want keyed arrays for form building and a Laravel validation rule from a single declaration, and you are not looking for casts, attribute casting, or framework-wide integration.
• You are prepared to vendor it. MIT license and small surface area mean you can fork or inline it. Only adopt if your team is comfortable owning that code path.

Look elsewhere, or build nothing at all, when:

• You are on PHP 8.1+. Native backed enums plus Laravel's Rule::enum() and enum casting cover the same ground with zero dependency. This is the default recommendation.
• You need an actively maintained ecosystem. Zero stars and zero dependents is a weak signal. There is no community to catch regressions, no issue triage history to inspect, and the upstream library it continues is itself a legacy artifact.
• You need more than constants and select arrays. If you want attribute casting, query scopes, TypeScript/JSON schema generation, or Filament/Nova integration, better-maintained packages exist in that space, and evaluating them is a real comparison rather than a formality.
• You have no legacy constraint and are choosing greenfield. Introducing a fork of a deprecated library into new code creates a migration debt on day one with no offsetting benefit.

How to Pitch It (Stakeholders)

For executives. This is a small, MIT-licensed PHP utility that keeps a fixed list of options — statuses, categories, tiers — defined in one place so that screens, validation, and stored data stay consistent. The strategic read is that it solves a real and recurring problem, but the specific package shows no adoption: no stars, no downstream dependents, and it exists only as a continuation of a library that has since been superseded. Recommendation is not to standardize on it. If our stack is on a modern PHP version, the platform now provides this capability natively at no cost and no maintenance burden, and that is where we should point engineering.

For engineering. Treat this as a candidate for a time-boxed evaluation, not a default. The package is a fork of eloquent/enumeration and inherits its design: constant-based enum classes with helpers for keyed/select arrays and a Laravel validation rule. The surface area is small and the license is permissive, so if we need it we can vendor it. The concerns are maturity signals — no community, no dependents, single-maintainer continuation — and the fact that it duplicates functionality now in the language. My ask is a short spike to confirm PHP version constraints and to inventory existing Enum usage; if we are on 8.1+, the outcome should be a migration plan to native backed enums rather than an adoption plan. If we are genuinely blocked on an older runtime, we adopt temporarily, document it as debt with an owner, and set an exit criterion tied to the next runtime upgrade.