Enum Basics Extension Laravel Package

Product Decisions This Supports

• Feature scoping for enum-heavy domains — any roadmap item that models statuses, roles, categories, or state machines (order lifecycle, onboarding stages, notification types) will benefit from a consistent helper layer instead of ad-hoc match statements and hand-written label maps. This package's stated scope is precisely that: basic utility functions over PHP enums.
• Build vs. buy (or "borrow") on boilerplate — the honest framing is that this is a pattern decision, not a vendor decision. A ~1-star, 0-dependent package is best treated as reference implementation: read the source, decide whether the helpers match our conventions, then either fork under our namespace or adopt a maintained alternative. This decision gates whether we spend engineering days re-implementing enum helpers on every new project.
• Standardization across projects — if we ship multiple Laravel services, agreeing on one enum helper contract (labels, options arrays for form selects, validation rule generation, API serialization) reduces review friction and onboarding time more than any single feature does.
• Admin/CRUD velocity — dropdown option lists, Rule::enum-style validation, and human-readable labels are the highest-frequency enum chores. Standardizing them is a measurable DX win on internal tooling and back-office features.
• Localization and API contract decisions — whether labels live in enums, translation files, or the database is an architectural choice this package touches. Deciding it early prevents a painful migration later.

When to Consider This Package

Consider it when:

• The stack is PHP 8.1+ / Laravel and enums are already the team's default modeling tool.
• The need is genuinely basic — labels, case lists, values, validation — and we do not need translation plumbing, DB-backed enums, or Filament/Nova integrations.
• We are willing to vendor or fork it (MIT license makes this cheap) and own the code, rather than depend on upstream maintenance.

Look elsewhere when:

• Maintenance signals matter. One star and zero dependents means no community validation, unknown test coverage, unknown CI, and no evidence of responsiveness to issues or PHP version bumps. Treat it as unvetted third-party code, not a dependency.
• Documentation is a blocker. The description is Portuguese-only; if the team is not Portuguese-speaking, onboarding cost rises and the package becomes a bus-factor risk.
• Requirements exceed "basic." Established alternatives (e.g. archtechx/enums, spatie/laravel-enum, bensampo/laravel-enum) or Laravel's native enum casting and Rule::enum cover the same ground with active maintenance — evaluate those first in any build-vs-buy comparison.
• Security/compliance review applies. Zero dependents and no release history make standard supply-chain review harder to justify than writing ~50 lines of our own helpers.

Recommended next step: a time-boxed one-day spike — read the source, run it against two real enums in our codebase, and decide fork vs. established package. Do not adopt as a direct Composer dependency without that review.

How to Pitch It (Stakeholders)

For executives: this is a low-cost developer-experience decision, not a platform bet. Enums are now standard in PHP, and every team writes the same helper functions repeatedly — labels, dropdown lists, validation. This package is a candidate shortcut, but its maturity is near zero (one star, no downstream users), so the recommendation is to learn from it, not depend on it: either copy the handful of functions we need under our own namespace or use a maintained alternative. Cost is measured in hours, reversibility is high, and there is no lock-in because the license is MIT.

For engineering: a thin, optional sugar layer over native enum behavior. Evaluate it as a reference implementation, confirm PHP/Laravel version support and test coverage, then either fork it internally or pick a maintained package. Decision owner: backend lead. Success metric: new enum-backed features ship without bespoke label/option/validation code, and we can swap the implementation in an afternoon.