Enum Bundle Laravel Package

Technical Evaluation

What the package actually is. Despite the "Laravel/PHP package" framing, yokai/enum-bundle is a Symfony bundle, not a framework-agnostic library. Its value is a class-based enumeration system (an abstract enum type, a manager/handler that resolves enum definitions, code-generation commands) wrapped in Symfony-specific glue: a DI extension and compiler pass, a Symfony Form type, a Validator constraint, a Twig extension, and a Doctrine DBAL custom type. That split matters for the evaluation: only a minority of the code is portable to Laravel, and that minority duplicates a language feature.

Architecture fit — weak. Laravel has no Bundle, DI-extension, or compiler-pass concept. Anything that depends on symfony/framework-bundle, symfony/form, symfony/validator, or Twig is dead weight in a Laravel service provider. More fundamentally, Laravel 10/11 require PHP 8.1+, which ships native backed enums. The package's core proposition — emulating enums with classes plus metadata — is largely redundant on the target runtime, and where it adds value (labels, option lists, DBAL mapping) that is 100–300 lines of in-house code, not a dependency.

Integration feasibility — low, with one narrow exception. The only component plausibly reusable outside Symfony is the Doctrine DBAL type, and only if the application already runs Doctrine ORM inside Laravel (uncommon; most teams use Eloquent). Attempting to install the bundle wholesale will pull Symfony Form/Validator/FrameworkBundle into a stack that does not use them: no fatal conflict, but unused surface area, an extra upgrade axis, and a misleading dependency graph for future maintainers.

Technical risk — moderate, driven by adoption, not code quality. MIT license, small codebase, and a recent release (2025-09-02) mean the code is inspectable and forkable. The risk is ecosystem signal: 12 stars, 0 dependents, no visible downstream usage. That implies a bus factor near 1, no published support/security policy, and no evidence of a BC policy across PHP, Symfony, and Doctrine DBAL major versions — the three axes most likely to break it. Attack surface is minimal (no network, no I/O, no deserialization), so security exposure is low; the real cost is upgrade tax.

Key questions to resolve before any commitment.

• Does the current release support or interoperate with PHP 8.1 native enums, or does it mandate its own base class (creating two enum dialects)?
• What are the hard composer.json requirements, and is there a framework-agnostic core that can be consumed without framework-bundle?
• Is the Doctrine type compatible with DBAL 3/4, and how does it handle values removed from the enum but still present in the database?
• Is the enum registry built at compile/cache-warmup time or resolved lazily per request?
• What is the maintainer's stated roadmap and BC commitment? Is there a test matrix across PHP and Symfony versions?
• Who owns the fork if the upstream stalls, and under what internal SLA?

Bottom line. Score 0.21 with opportunity 25.19 is consistent with "reference implementation, not a dependency." Recommend do not adopt as a Laravel dependency; treat the repository as a design reference (or a bounded fork) if a specific capability is needed.

Integration Approach

Stack fit, component by component. Map each Symfony-facing feature to its Laravel equivalent and reject the ones that don't translate:

Recommended implementation instead. Create a small internal convention in app/Support/Enums: native backed enums implementing a marker interface (e.g. HasLabel/HasOptions), a trait supplying label() and options(), an Eloquent cast, and a Rule::enum()-based validation rule. This mirrors the package's ergonomics at a fraction of the dependency cost, is idiomatic for new hires, and gives full IDE support.

Migration path, if enums already exist as class constants or arrays. (1) Inventory constant-holding classes and string-typed columns. (2) Convert one bounded context at a time to native backed enums, keeping persisted string values identical so no data migration is required. (3) Add the cast and validation rule alongside, not before. (4) Only after two contexts ship cleanly, retire the legacy pattern via static analysis (PHPStan/Rector rule) so the old style cannot creep back.

Compatibility constraints. Do not run both dialects simultaneously — if any part of the org has Symfony services using this bundle, keep them where they are and integrate across a data contract (the string value persisted in the shared database), never by sharing the library. For the DBAL type, confirm stored representations are plain scalars before assuming a drop-in swap; a mismatch means a backfill migration against production data, which should be scheduled and reversible.

Sequencing.

1. Week 1 — spike (2–3 days). In a single bounded context, prototype the native-enum pattern and, in parallel, attempt to load the bundle in a Laravel skeleton to document exactly what breaks. The spike's output is a written decision, not code.
2. Week 2 — decision gate. Unless the spike surfaces a capability that cannot be replicated in under ~2 days of work, close the evaluation as "not adopted" and record the rationale in the ADR log.
3. Conditional fork. If a capability does justify reuse, vendor only the isolated classes (Doctrine type, manager) into a namespaced internal package pinned to a commit, with a NOTICE preserving MIT attribution. Budget for ownership from day one.

Operational Impact

Maintenance. MIT and a compact codebase make a fork technically easy, which is exactly the trap: forking transfers the full upgrade burden in-house. Expect 2–5 engineer-days per year of baseline upkeep, plus a spike of several days each time PHP, Symfony, or Doctrine DBAL cuts a major. If adopted un-forked, you inherit the maintainer's release cadence with no contractual influence over it.

Support. GitHub issues only. No published SLA, security policy, or LTS commitment, and no commercial backing visible. Internal escalation path terminates at your own team; a P1 caused by an upstream bug has no vendor lever. Mitigation is architectural (isolate behind an internal interface) rather than procedural.

Scaling. Runtime cost is negligible: the code is stateless and CPU-cheap, and horizontal scaling is unaffected. The one thing to verify is registry construction — if the manager eagerly materializes all enum definitions on container boot, a large enum catalogue becomes per-request overhead on every worker; that is cacheable at build time, but confirm before assuming it is free.

Failure modes to instrument.

• Hydration/conversion errors when a persisted value no longer exists in the enum after a value is removed — the highest-severity failure, and it surfaces in production reads, not in CI.
• Container/compile failures on framework upgrades, which are loud and block deploys rather than degrading gracefully.
• Silent validation gaps where the form/validator layer and the domain layer disagree about the valid set, admitting bad data quietly.
• Dialect drift — half the codebase using native enums, half using the package's classes, producing confusing review discussions and inconsistent serialization.
• Class-map collisions if a fork is vendored without renaming the namespace.

Ramp-up. A competent Laravel developer learns the API in half a day; the docs are Symfony-centric, so every example needs translation and the first real question lands on the adopting team. The larger cost is negative transfer: developers internalize a bespoke enum idiom that diverges from the language feature they will use everywhere else, degrading code-review quality and slowing onboarding for subsequent hires. By contrast, native backed enums carry zero ramp-up cost because they are already in the PHP manual and every IDE.