Enum Bundle Laravel Package

Technical Evaluation

Architecture fit — negative at the bundle layer, conditional at the core layer. The EnumBundle naming is Symfony convention: bundles are registered through a kernel, shipped with Flex recipes, and wired via a DependencyInjection/*Extension.php config tree. Laravel has no equivalent abstraction, so the bundle half of this package is dead weight in our stack — at best inert, at worst an autoload or boot-time failure. The underlying enum implementation, if it is separable as a plain Composer package, is framework-agnostic PHP and could in principle be consumed in Laravel. That is an unverified assumption and the single most important thing to check.

The core value proposition is largely obsolete. PHP 8.1 shipped native backed enums, and Laravel now covers the adjacent ground natively: enum casting on Eloquent attributes, Rule::enum() validation, ->enum() migration columns, and enum-aware factories. A userland enum library only earns its place if it offers something materially beyond that — instance maps, ordering/ordinal semantics, label lookup, coercion helpers. The package description claims validation, serialization, and transformation helpers, and those are real, but they are also the ~50–100 lines we would otherwise write ourselves. This is a build-vs-borrow decision on a micro-utility, not a platform adoption.

Integration feasibility — low-friction on paper, high-friction in practice. Two blockers are likely and both are cheap to test:

• Composer resolution. Symfony bundles carry symfony/* version constraints that collide with the symfony/* transitives Laravel already pulls in (console, http-foundation, routing, finder). Expect composer require to fail against our locked set before any code is written.
• Inheritance model. Pre-8.1 enum libraries typically model enums as classes extending an abstract Enum base. Native enum types cannot extend classes and cannot be instantiated. If that is the design, adopting this package means committing to a class-based value-object pattern that is architecturally incompatible with native enums — and because you cannot incrementally convert a class hierarchy into native enums, that is a one-way door.

Technical risk — high. Zero stars, zero dependents, zero downstream usage, and a score of 0. There is no evidence any production system runs this, no issue corpus to learn from, no ecosystem pressure to catch regressions, and a bus factor of one. For anything that touches persistence or serialization boundaries — which is exactly where enums live — that risk profile is unacceptable without a deliberate fork-and-own decision. Absent the checks below, the correct default posture is "pattern to copy," not "package to depend on."

Key questions to resolve before a line of code:

1. Which repository contains the enum implementation versus the bundle glue? Can we depend on the core alone and drop the bundle entirely?
2. What are the declared PHP and symfony/* constraints, and do they resolve against our current Laravel version and PHP floor/ceiling?
3. Is the enum a class extending an abstract base (incompatible with native enums), a trait, a set of static helpers, or something else?
4. What does it provide that native enums plus Laravel casting and Rule::enum do not? Produce a line-by-line gap list.
5. Is there a changelog, CI pipeline, or tag history — and when was the last commit?
6. License and autoload namespace; does anything assume a Symfony kernel at boot?
7. Are there any real consumers we can contact, even privately?

TPM framing. Treat this as a dependency-governance decision with a written decision record, not as a feature request. The deliverable is a go/no-go with a named owner, an expiry date, and a documented exit ramp — not an integration ticket.

Integration Approach

Stack fit. Negative at the bundle layer; neutral-to-conditional at the core layer. My recommendation is to not adopt the bundle and to adopt the core library only if question 4 surfaces a concrete capability we actually need. The default path — native PHP 8.1 enums, Eloquent enum casting, Rule::enum, and one small internal trait for values()/labels()/options() — replaces the library's entire surface area with roughly 50 lines we own outright, with zero dependency risk and full static-analysis and IDE support.

Migration path. If we proceed at all, run it as a timeboxed spike on a scratch branch, never on main:

• Attempt composer require against the locked dependency set and capture conflict output verbatim — this output is the artifact that ends the discussion cheaply if it fails.
• Define one representative enum (e.g. OrderStatus), persist it through Eloquent, validate it via a FormRequest, serialize it through a queued job, and render it in an admin select.
• Diff the feature set against native enums line by line and record only the true gaps.
• Because a class-based enum model cannot be incrementally converted, price any adoption as irreversible.

If we adopt, wrap it behind an internal contract — a HasLabels / HasValues interface in our namespace — so no call site references the vendor namespace. That abstraction is the exit ramp and costs one extra hour.

Compatibility. Test on the lowest and highest PHP versions we support and on the current Laravel major plus the prior one. The symfony/* transitive constraints are where I expect the spike to fail, and that failure is itself a valid, cheap outcome worth publishing to the team.

Sequencing (with gates):

1. Feature inventory read from source — documentation is thin to nonexistent. Owner: dev. Gate: gap list exists.
2. Composer feasibility spike — hard gate. Fail here and the decision is made.
3. Native-enum gap analysis — hard gate. If the gaps are label maps and a cast, stop.
4. Build-versus-borrow decision, with a written default to build; require an explicit justification to override.
5. If adopted: pin an exact version, add contract tests around every consumed method, document the fork procedure, and assign an owner.
6. If declined: record the decision and adopt native-enum conventions in our engineering standards so the question does not resurface in three months.

Keep the whole evaluation inside one sprint. This is a small decision that should not acquire a steering committee.

Operational Impact

Maintenance. Adoption means we own this code in all but name. With no active upstream community, Laravel and Symfony major upgrades become our incident to absorb, and a symfony/* bump anywhere else in the tree can break installs without warning. Budget ongoing ownership cost, not a one-time integration cost — and note that the ownership burden is disproportionate to the code's size because it sits in the domain layer where every service touches it.

Support. No vendor, no maintainer SLA, no forum, no Stack Overflow corpus. Internal expertise is the only support channel. That is defensible for a small utility with a named owner; it is not defensible for something every entity and API resource depends on.

Scaling. Runtime cost is negligible — enum resolution is CPU-trivial and will never appear in a profile. The real scaling concern is surface area: the more places an enum instance is persisted, cached, or queued, the more a change to the class shape becomes a breaking change. Enforce a standing rule that only scalar backed values cross storage, cache, and queue boundaries — never enum instances. That rule is good hygiene regardless of which path we choose, and it is the single highest-leverage mitigation available.

Failure modes to watch:

• Composer resolution failure in CI or on a fresh clone, blocking onboarding and deploys.
• Minor-version breaking changes from unpinned constraints, or a force-push to dev-master.
• Silent coercion drift — int versus string backing — producing data-integrity divergence at the database boundary that surfaces as bad reports weeks later.
• Autoload failures under composer dump-autoload --optimize if bundle classes assume Symfony's kernel registration.
• Deserialization failures for queued or scheduled jobs holding enum instances after a refactor — jobs fail after deployment, which is the worst possible time to discover it.

Ramp-up. Technically low: an afternoon of source reading for a mid-level PHP developer. The cost that matters is organizational. Every new hire must learn a bespoke enum pattern that no longer appears in the wider PHP ecosystem, and every reviewer must police its boundaries. That tax compounds indefinitely against a native-enum alternative that the language itself maintains and every PHP developer already knows.

TPM recommendation. Decline the bundle. Approve a one-day spike to confirm the core library offers nothing we cannot write in an afternoon, then standardize on native PHP 8.1 enums with a small internally owned trait, captured as an ADR with a named owner and a revisit trigger (e.g. "revisit if three teams independently reimplement label maps"). This converts an unbounded dependency risk into a bounded, owned, 50-line asset — and gives stakeholders a cost of near zero with the maintenance exposure capped and documented.