Laravel Enum Laravel Package

Product Decisions This Supports

• Modelling domain state as native enums vs. lookup tables. The package makes PHP 8.1 backed enums viable as the system of record for statuses, states and categories (order lifecycle, payment state, ticket status, notification channels). That is a durable schema decision: enums live in code and ship with the release, lookup tables live in the database and change at runtime. This package lowers the cost of the "enums in code" path, so the decision can be made primarily on product grounds (do values change without a deploy?) rather than on tooling friction.
• Build vs. buy for enum plumbing. Most teams eventually hand-roll a trait for labels, a match statement for display names, a custom validation rule, and a cast for multi-select fields. That is typically 100–300 lines of undifferentiated glue per codebase, duplicated per team. Adopting a small MIT package (or consciously deciding to fork it) is a decision worth recording, not defaulting into.
• API contract and validation posture. Enum-aware validation rules let you reject invalid payloads at the boundary instead of deep in domain logic. This directly supports decisions about how strict the public API is, how much defensive coding the domain needs, and how much of a class of "impossible value" bugs QA has to chase.
• Fixed taxonomy vs. user-configurable taxonomy. Enums with metadata make the closed set of values visible to product and design. If the roadmap includes "let admins add custom statuses," that is a signal to look elsewhere; if the set is genuinely closed, this is the cheapest representation.
• Permissions and capability modelling. Bitwise flag support makes it feasible to model composable capabilities (read/write/approve/export) in a single integer column without a join table, which is a real architectural choice with query and migration consequences. Note that this is not a replacement for a proper authorization package — it is the storage and ergonomics layer only.
• Localisation and admin UI scope. Attribute-driven labels/descriptions mean display strings can be colocated with the enum and translated, rather than scattered across Blade templates and front-end constants. That affects how much of the admin surface can be generated or standardised.
• Standardisation and onboarding cost. If several teams are writing enum helpers independently, adopting one convention (this package, or a thin internal wrapper over it) is a platform decision that reduces review surface and cross-team inconsistency.

When to Consider This Package

Adopt when most of the following hold:

• You are on PHP 8.1+ and a Laravel version the package explicitly supports — verify the compatibility matrix against your matrix before committing, since enum support and Laravel's own casting behaviour changed across 9.x/10.x/11.x.
• Enums appear in at least three places at once: Eloquent casts, request validation, and presentation (labels, dropdowns, API docs). Single-use enums do not justify a dependency.
• You need metadata or behaviour that core Laravel does not give you. Be honest about the delta: Laravel core already offers enum casting and an Enum validation rule, so the genuine differentiators here are attribute-based metadata, flag/bitmask handling, and enum collections. If you only need casting, use the framework.
• You want flags or multi-select semantics without a pivot table.
• You have a policy that tolerates small, single-maintainer dependencies — or you are willing to vendor/fork it. MIT licensing makes that cheap, which is the strongest argument in its favour.
• Multiple teams are duplicating helper code and you want one convention.

Look elsewhere when:

• You need state transitions with guards and side effects — use a workflow/state-machine package; an enum describes the states, not the legal moves between them.
• You need roles and permissions enforcement — use a dedicated authorization package; flags here are storage ergonomics, not an ACL.
• The value set changes without a deploy (per-tenant statuses, editable categories). Stay with a lookup table.
• You are pre-8.1, on an unsupported Laravel version, or in a regulated environment with a hard dependency-approval bar that a 189-star, single-maintainer package will not clear.
• Your enum needs are trivial and a 20-line trait would do.

Risk notes to carry into the decision: 189 stars and zero recorded dependents is a thin adoption signal, and a single maintainer is a bus-factor of one. That is manageable for a convenience dependency that sits behind an internal interface, and unacceptable for one that business-critical logic calls into directly. Pin the version, wrap it, and treat the wrapper as the contract.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, MIT-licensed developer-ergonomics library that makes Laravel's native enum feature practical for production use — labels for the UI, validation at the API boundary, and multi-select flags without extra database tables. It is not a customer-facing capability and it will not move a metric on its own. The case is engineering efficiency and defect reduction: it removes duplicated boilerplate across teams and closes off a recurring class of "invalid status" bugs. Cost is near zero to try and near zero to reverse.

To engineering leadership: It replaces hand-rolled enum traits, scattered match display-name blocks and bespoke validation rules with declarative attributes, plus casting and flag support. Realistically it saves days, not months — the value compounds only if you standardise on it, because the win is consistency across teams rather than any single feature. The honest caveat is that core Laravel already covers plain casting and enum validation, so the incremental value is concentrated in metadata and flags.

To risk/architecture reviewers: Low blast radius if adopted correctly. Pin the version, put it behind an internal App\Support\Enums interface, and never call the package directly from domain logic — that keeps an exit to a fork or a homegrown replacement to roughly a day's work, which the MIT licence permits. Do not let it become load-bearing for authorization or state-machine behaviour; it is not built for those.

The ask: Approve a one-service, one-to-two-sprint pilot on a domain with a genuinely closed value set — order status or notification channels. Success criteria: helper code deleted, no enum-validation defects in the pilot window, and no new friction for engineers unfamiliar with the API. If it clears, standardise the wrapper internally; if not, the sunk cost is a sprint of one engineer's time.