Enum Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged, and still the headline risk. lamoda/enum-bundle remains a Symfony bundle, not a Laravel package. Its value is entirely framework glue: a Bundle class, a DI extension, compiler passes that tag enum-aware services, a Doctrine DBAL type, a Symfony Form EnumType, a validator constraint, and Twig helpers. Laravel has no equivalent subsystems for any of these. In a Laravel codebase the package is inert; adoption means pulling in symfony/form, symfony/validator, symfony/twig-bridge, and Doctrine bridge code we cannot use. Release 1.6 does nothing to change this — it is a version-constraint edit, not a feature or port.

The underlying abstraction is still dated. The bundle wraps php-enum, the pre-8.1 pattern of classes extending a base Enum with class constants. PHP 8.1+ native enum plus Laravel's Rule::enum, Eloquent enum casts, and BackedEnum JSON serialization already cover ~90% of the functionality with zero dependencies. 1.6 does not modernize the abstraction; we would still be adopting a second, non-idiomatic enum vocabulary.

What 1.6 actually changes. The release note is a single line: "allow symfony 6 version." Read literally, this is a composer.json constraint widening that unblocks Symfony 6 coexistence. That is the single most useful thing upstream could have shipped short of a rewrite, because it retires the near-term upgrade-blockage risk we flagged. It does not evidence new features, a PHP 8.3/8.4 floor declaration, a security or triage process, or a community forming around the package. Treat it as "not abandoned," not as "actively maintained."

Integration feasibility: low for Laravel, and modestly improved for Symfony. Realistic options remain (a) use it only if the target service is genuinely Symfony/Doctrine — now viable on Symfony 6 as well as 5, (b) vendor a thin internal equivalent (~150 LOC: base trait, validation rule, Eloquent cast), or (c) do nothing and standardize on native enums. Option (a) is still the only case where the package earns its keep, but its coverage window is now wider.

Technical risk signals — one positive, several unchanged. Positive: a release landed after a long quiet period, so the project is not dead. Unchanged concerns: negligible downstream cohort (no dependents to absorb breakage before it reaches us), no visible CVE or advisory pipeline, no issue-triage cadence, and a one-line release note with no changelog. A constraint-only release with no migration notes also raises a specific question we must answer ourselves: did 1.6 widen the constraint to include Symfony 6, or replace Symfony 4/5 support outright? If it replaced, 1.6 is a breaking change for anyone already pinned to 1.5 and our upgrade path needs a composer why-not check rather than an assumption. MIT licensing remains clean, so forking is legally trivial — but forking still means we own it.

Key questions for the team:

• Is the target service actually Symfony, or is this scoped against Laravel? Unchanged, and still decisive.
• Does 1.6 widen or replace the symfony/* constraint? Diff composer.json between 1.5 and 1.6 before planning anything; do not rely on the release note.
• Does 1.6 pull newer transitive Symfony 6 components that conflict with our pinned versions? Constraint widening often drags dependency drift with it.
• Is the real requirement typed enum DB columns, server-side validation, form rendering, or just "use enums"?
• What is the PHP floor and ceiling? 8.1+ makes native enums the default answer; 8.3/8.4 support is still unproven by any release artifact.
• Does the estate already use Doctrine DBAL, or is it Eloquent-only?
• Are there existing classes extending Lamoda\Enum\Enum we must remain compatible with?
• Who owns maintenance if upstream stalls again — do we have budget to fork and pin?
• Which Symfony/Laravel majors are on the roadmap beyond 6, and is there any reason to believe this package will track them?

Integration Approach

Stack fit. Unchanged: poor for Laravel, good for Symfony. Do not install this into a Laravel application and shim the bundle machinery — the effort exceeds the cost of writing the equivalent internally and leaves a permanent abstraction mismatch. For a Symfony + Doctrine target the bundle remains a natural, low-ceremony fit: register in bundles.php, map enum classes to DBAL types in doctrine.yaml, use EnumType in forms.

Recommended path (build vs. adopt):

1. Spike first, ≤3 days. Confirm framework targets, then run composer why-not lamoda/enum-bundle 1.6 against our current and next framework versions. 1.6 removes the most likely blocker here, so this step is now materially cheaper and more likely to succeed than when first assessed — but it is not a formality. Verify the constraint change is additive.
2. If Symfony/Doctrine: adopt the bundle in a single bounded service, register DBAL types explicitly, and wrap access behind an internal helper so removal is a one-file change. Pin to 1.6 for the Symfony 6 headroom.
3. If Laravel or framework-agnostic: skip the dependency. Native backed enums plus a validation rule and an Eloquent cast is roughly a day of work, no third-party surface area, and it survives every future framework upgrade. 1.6 does not move this recommendation.

Compatibility checks before committing. Diff the symfony/* constraint range between 1.5 and 1.6 (widen vs. replace); verify PHP upper bound remains unstated and test on our actual 8.3/8.4 targets; verify whether Doctrine DBAL is a hard or soft requirement; verify the DBAL type's behavior on unknown stored values (throw vs. silent coercion); confirm the transitive Symfony 6 components 1.6 resolves to match our pinned set.

Migration sequencing (assuming a decision to proceed in a Symfony context):

1. Audit existing enum-like constants and the DB columns/serialized payloads they map to.
2. Pin and record the 1.5 → 1.6 constraint delta in the service's ADR, so the next reader knows why 1.6 was chosen.
3. Pilot in one low-blast-radius domain (e.g., order status) — not a core money path.
4. Install and register; back the pilot column with the DBAL type; add form and validation usage.
5. Instrument: confirm no value drift between code and stored data across a full read/write cycle.
6. If successful, extend domain-by-domain. If not, unwind — the adapter layer keeps this cheap.
7. Separately, converge on native enums as the long-term idiom; treat php-enum-style classes as legacy to be retired, not a pattern to propagate.

Operational Impact

Maintenance. Unchanged in substance: assume we own this from day one. 1.6 is evidence of occasional upkeep, not of a support commitment — a single constraint commit after a long gap tells us the maintainer responds to their own needs, on their own schedule. Zero dependents means no one else files the issues that would surface breakage early. Budget for a pinned fork or a .composer constraint lock, plus a named internal owner.

Support. Documentation is still effectively the README, and 1.6 shipped without a changelog — we had to infer the change from a five-word note. No community, no discussions channel, no Stack Overflow corpus; every question becomes an internal investigation. Bus factor remains 1–2 people; at least two engineers must understand the DI wiring and DBAL type mapping.

Scaling. Runtime scaling is a non-issue — the bundle is thin and adds no meaningful overhead. The scaling cost is organizational and cognitive: every engineer who touches an enum must learn a non-standard idiom that differs from native PHP enums. That tax compounds with team size and onboarding rate, and it is paid forever, whereas the benefit is collected once.

Failure modes, ranked by expected cost:

• Dual enum idioms (now highest). Native enums and php-enum classes coexisting produces subtle bugs at serialization boundaries, JSON API contracts, and queue payloads. With the Symfony-upgrade blocker largely retired by 1.6, this becomes the leading residual risk. Mitigation: one idiom per service, enforced in review.
• Upgrade blockage when Symfony 7 lands (downgraded). 1.6 clears the Symfony 6 hurdle but says nothing about 7. Given the cadence, assume a repeat of this gap and plan the adapter seam accordingly. The trade is now "we may be stuck later" rather than "we are stuck now."
• Silent data drift. If the DBAL type does not validate on read, invalid stored values surface as runtime exceptions far from the write that caused them. 1.6 does not touch this. Verify throw-vs-coerce behavior explicitly during the pilot.
• Silent constraint regression. If 1.6 replaced rather than widened the Symfony 4/5 range, teams pinned to 1.5 face a surprise break on composer update. Mitigation: read the manifest, pin exact versions, and diff in the spike.
• Bootstrap failure. Missing bundle registration or stale container cache yields opaque "type not found" errors at runtime rather than at deploy. Standard in Symfony, but worth a smoke test in CI.
• Abandonment with no security path. No advisories pipeline means a vulnerability in this package or its transitive Symfony deps would not be surfaced to us. Unchanged by 1.6; we monitor the fork ourselves.

Ramp-up. A Symfony-fluent engineer is productive in 1–2 days; 1.6 adds nothing to learn. A Laravel-first team should not attempt ramp-up at all — the correct cost estimate for that scenario is the cost of building the internal equivalent, not the cost of learning this bundle.

TPM recommendation. Unchanged in direction, slightly softened in urgency. Do not adopt for a Laravel target — the framework mismatch is disqualifying and native enums already cover the gap. For an existing Symfony + Doctrine service, 1.6 upgrades this from "adopt only with a funded fork plan" to "adopt in a bounded service with an adapter seam, a pinned version, and a named owner," contingent on the spike confirming the constraint change was additive rather than a replacement. Everywhere else, take the one-day internal build and keep the dependency count flat.