Enum Getter Laravel Package

Product Decisions This Supports

• Standardizing enum handling across the stack. v2.2.0 adds fromKey, closing the round-trip gap between storing an enum key (DB column, API payload, config value) and hydrating the corresponding enum case. This supports a single convention for keys vs. labels instead of scattered match/switch blocks in controllers, resources, and form requests.
• Storage and API contract decisions. Teams can now standardize on storing enum keys (stable, language-independent) while exposing labels only at the presentation edge. fromKey with explicit error handling makes invalid-key handling a deliberate decision (validate-and-reject vs. fallback) rather than an implicit null.
• Build vs. buy. The package is a thin helper layer over native PHP backed enums. If your codebase has multiple enums with repeated key/label/value mapping, buying (adopting) is cheaper than maintaining an internal EnumHelper trait; if you have one or two enums, native enum methods plus Laravel’s enum casting are likely sufficient.
• Roadmap fit. Low-risk, low-ceremony dependency suitable for admin panels, settings screens, feature-flag/status fields, CSV import validation, and form select generation (key => label) where enums drive UI options.
• Upgrade decision for v2.2.0. This is a minor, additive release: new fromKey method plus documentation clarifying the keys-vs-labels distinction and native enum methods. Non-breaking from v2.1.1; safe to adopt on the next maintenance window.

When to Consider This Package

Adopt when:

• You have several enums and are repeatedly writing the same key/label/value accessors, or you need fromKey-style reverse lookup with explicit failure behavior for untrusted input (request payloads, imported files, DB rows written by older code).
• You want a consistent keys-vs-labels convention across API resources and UI, and prefer a small, focused dependency over an in-house trait.
• You are on a supported PHP/Laravel version with native backed enums and want helpers that complement, not replace, Laravel’s enum casting.

Look elsewhere or defer when:

• You have a single enum or trivial mapping needs — native cases(), from(), and tryFrom() cover most of it.
• You need rich domain behavior on enums (state machines, permissions, complex metadata), framework-agnostic usage outside Laravel, or heavy i18n label resolution beyond simple label lookup.
• Vendor-risk tolerance is low: this is a small, single-maintainer package. Review test coverage, release cadence, and supported PHP/Laravel versions before making it a broad dependency. Pilot on one or two enums first.

How to Pitch It (Stakeholders)

For executives: This is a small utility that removes repetitive glue code around PHP enums and makes status/type values consistent between what we store, what our APIs return, and what customers see in labels. v2.2.0 adds a safer way to turn a stored key back into an enum value with explicit error handling — reducing silent failures when data or user input is malformed. Risk is low: it is an additive minor release with no breaking changes, and the dependency footprint is minimal. Recommendation: pilot on a couple of enums, confirm it removes boilerplate, then standardize.

For engineering: v2.2.0 introduces fromKey for reverse lookup with error handling, plus clarified docs on the key-vs-label distinction and native enum methods. This lets us store stable keys, render labels at the edge, and make invalid-key handling explicit instead of implicit. It complements Laravel’s native enum casting rather than replacing it. Upgrade is non-breaking from v2.1.1. Before broad adoption, sanity-check supported PHP/Laravel versions and test coverage given the single-maintainer project.