Enum Bundle Laravel Package

Product Decisions This Supports

• Domain-modeling: enums vs. strings vs. lookup tables. Whether lifecycle fields (order status, subscription state, KYC stage, notification channel, feature-flag name) live as native PHP 8.1 backed enums or as loose string constants. This package's only real job is making the enum option more ergonomic — a shared values()/labels()/options() helper surface — so the decision it informs is "do we standardize on enums across the domain model," not "do we adopt this library."
• Build vs. buy vs. fork. The honest framing is a micro-utility decision: write a ~50-line internal trait, fork this, or depend on it directly. Scope is small enough that ownership and maintenance, not capability, should drive the call. Default position should be build or fork, not depend.
• API and data-contract consistency. How enum values surface in JSON responses, validation error messages, and admin dropdowns. One canonical label map eliminates the "every endpoint formats status differently" problem — a recurring PM-visible bug class.
• Admin/UX surface. Label and option helpers directly power dropdowns, filters, and status badges in whatever admin panel we use, giving the PM a single source of truth for what users see versus what the database stores.
• Roadmap (indirect). Enum ergonomics is platform plumbing, not a roadmap line item. It accelerates any status- or workflow-driven feature (approvals, onboarding state machines, entitlements) but should never appear on a roadmap as work itself.
• Representative use cases: enforcing valid state transitions, whitelisting config values, readable audit-log entries, and consistent feature-flag naming across services.

When to Consider This Package

• Framework fit is the first gate — and it likely fails for us. Despite being framed here as a "Laravel/PHP package," the name and description point to a Symfony bundle. Laravel has no bundle convention (no registerBundles(), no Flex recipes), so the bundle layer is dead weight and may not autoload cleanly. Confirm a Laravel service provider and Eloquent integration actually exist before scoping any work; if they don't, this isn't a Laravel decision at all.
• Value proposition is largely obsolete. PHP 8.1 native backed enums plus Laravel's built-in support — Eloquent enum casting, Rule::enum(), ->enum() migration columns — cover most of what a userland enum library used to provide. Adopt only if a concrete capability gap exists (instance maps, ordering semantics, label lookup, coercion helpers) that native enums don't cover.
• Legitimate fit: PHP 8.1+ with backed enums already in use, multiple teams duplicating toArray()/labels()/options() traits, and a genuine win from centralizing them. Restrict to prototypes, internal tools, or low-blast-radius services.
• Adopt only as vendored source. Pin an exact commit, read the source, check tests, PHP/symfony/* constraints, and license — then treat it as a fork you own, not a live dependency.
• Look elsewhere when: the code is production-critical, you need guaranteed maintenance, i18n label integration, or framework-native Eloquent casts and validation rules. Mature options (bensampo/laravel-enum, archtechx/enums) or plain native enums plus a custom cast cover most needs.
• Adoption signals are all negative: 0 stars, 0 dependents, score 0 — no community validation and no downstream usage to learn from. Default to "pattern to copy," not "package to depend on." A one-day spike comparing its API against a ~40-line internal trait should be the most we commit.

How to Pitch It (Stakeholders)

To executives: This is a small, near-zero-cost utility that removes an entire class of bugs — invalid or inconsistent status strings leaking into the database, APIs, and UI — and speeds delivery of any status- or workflow-driven feature. The code is tiny enough to fork and own internally, so maintenance risk is contained. Two caveats: it has no adoption and appears to be a Symfony bundle, so it may not fit our Laravel stack without adaptation. Recommendation: approve a short, timeboxed evaluation, not a production dependency.

To engineering: It's a thin helper layer over native PHP 8.1 enums — value/label maps, validation, casting. Given zero stars, zero dependents, and probable Symfony-only packaging, treat it as reference code: spend a day diffing its API against a ~40-line internal trait and against established alternatives (bensampo/laravel-enum, archtechx/enums), then either fork it under our namespace or reimplement only the parts we use. Either way we own the code, avoid an unpinned third-party dependency in the domain layer, and keep full static-analysis and IDE support. Hard gates before any integration: Composer resolution against our locked set, and a written native-enum gap analysis — if neither clears, the answer is "build," and we record that decision in our standards.