Laravel Enum Laravel Package

Product Decisions This Supports

• Domain modeling of state. Status, type, and role fields (order status, payment state, subscription tier, notification channel) become typed values instead of magic strings. This is the decision that matters: invalid states become harder to represent, and refactors become compiler/IDE-visible rather than grep-and-pray.
• Localization as configuration, not code. Labels living in lang/ files means translating a status badge or dropdown is a content change, not a deploy. That directly affects whether "add Spanish to the admin panel" is a half-day or a two-week roadmap item.
• Data-integrity posture at the persistence boundary. Casting on Eloquent models means invalid values fail on read and write rather than silently propagating into reports. This is a decision about where you enforce validity — model layer vs. DB constraints vs. validation rules — and it should be made deliberately.
• Build vs. buy vs. use-the-language. The real decision here is rarely "this package or nothing." It's "custom base class vs. this package vs. native enums vs. a larger enum library." This package's honest role is as the legacy fallback: it makes the cheap case (Laravel ≤ 8 / PHP < 8.1) cost near zero.
• Convention enforcement. A make:enum generator is a process decision disguised as a tool — it says "every enum in this codebase looks the same and lives in the same place." Worth adopting for the convention even if the runtime features are thin.
• Roadmap input. Enum standardization is a low-effort cleanup that unblocks stable API contracts and admin/reporting surfaces. It is not a feature; treat it as enabling work with a small, bounded budget.
• Explicit non-goal. Semantic/reporting meaning should live in the database or analytics layer, not in PHP enum cases. Keep this out of scope or you will be redeploying to rename a label.

When to Consider This Package

Consider it when:

• The codebase is on Laravel ≤ 8 or PHP < 8.1, where native enums are unavailable and you need typed values plus model casting.
• You specifically want label translations via lang files with no bespoke plumbing.
• You want a generator-driven convention so new enums are uniform across teams.
• The work is greenfield-ish or a contained refactor, and you can absorb the convention now rather than migrating later.

Look elsewhere when:

• PHP 8.1+ / Laravel 9+. Native backed enums plus Laravel's native enum casting and Enum validation rule cover the large majority of this package's surface with zero dependency. This is the default recommendation.
• You need richer behavior — comparison helpers, attribute metadata, flags/bitmask handling, framework-agnostic enums. Mature libraries (bensampo/laravel-enum, archtechx/enums) cover this with active maintenance.
• You need maintenance guarantees. Zero stars, zero dependents, and a composite score of 0 are not quality judgments — they are maintenance signals. There is no community to catch a break on a future Laravel release. Do not put it on a critical path.
• You have two or three enums. A native enum or a class of constants is cheaper than any dependency, including this one.

Adoption hygiene if you do proceed: pin the version; note that the package is small enough to vendor or fork outright (which is the real mitigation); add a test asserting every enum case has a label key, because missing translations fail silently in the UI.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small developer-ergonomics library that makes status and type values in our code typed and their display labels translatable. The value is fewer production bugs from typos and invalid values, and cheaper localization of the admin surface. Cost is effectively zero and lock-in is negligible — the library is small enough that we could replace it in about a day. That low exit cost is the point: it is a convenience, not a platform. We should not build roadmap or commitments on top of it, and on any new service we'd use the language's built-in enums instead.

To engineering: It gives you a generated enum base class, Eloquent casting, and label lookups through lang/ files — the three things people hand-roll badly. The catch is that it predates native PHP 8.1 enums, and Laravel 9+ now ships the casting behavior natively. So the recommendation is: adopt it only where we're stuck on older Laravel/PHP, follow the pattern it enforces everywhere, and treat the package itself as disposable. Migration path to native enums is mechanical — the enum cases port directly, and the labels move to a match or a small helper. Budget roughly a day per service when we get there; it should be folded into existing work rather than scheduled as its own initiative.