Consistence Bundle Laravel Package

Technical Evaluation

Architecture fit — poor as-is. Despite the "Laravel/PHP" framing, mhujer/consistence-bundle is a Symfony bundle, not a Laravel package. Its value is delivered through Symfony-specific seams: a bundle class, a DI extension loading service definitions, a translator decorator wired to symfony/translation, and form types (enum select / multi-enum select) built on symfony/form. Laravel has no bundle registration, no symfony/form, and no tag-based container conventions, so none of that wiring activates. What is actually portable is the pattern: mapping a Consistence\Enum\Enum case to a translated label, and mapping the enum's available values to a choice list for input widgets.

Integration feasibility — feasible only as a reimplementation. The domain surface is small. A Laravel equivalent is roughly a EnumTranslator service (wrapping __() / Translator::get() with a enums.{class}.{value} key convention), a Rule::enum()-backed validation rule, and a Blade <x-select-enum> / FormRequest macro. That is on the order of one to two developer-days, versus an unbounded porting effort for the bundle itself. The bundle's real utility — "labels come from translation catalogs, not from hardcoded arrays" — is trivially reproducible in Laravel and is where the leverage sits.

Technical risk — high, mostly abandonment risk rather than runtime risk. Signals: 1 star, 0 dependents, an opportunity score of 17.5, single maintainer, and a name that pins it to the Symfony 3/4 era. The underlying consistence/consistence library predates PHP 8.1 native enums and carries a PHP 7.x-era constraint profile; running it on PHP 8.2/8.3 raises deprecation and static-analysis friction with no upstream fix path. Composer may technically resolve the bundle alongside Laravel's Symfony components, but installing symfony/framework-bundle into a Laravel app to gain an enum-to-label helper is a disproportionate dependency and an attack-surface increase for near-zero benefit. MIT license is clean, so forking is legally unencumbered.

Key questions for the team:

• Do we already have consistence/consistence enums persisted in a database, or is this greenfield? Persistence determines whether case values are a contract.
• What is the target Laravel and PHP version? If PHP ≥ 8.1, native backed enums plus Rule::enum() cover 80% of the bundle's value.
• Do we need MultiEnum-style set semantics (bitmask/combined values) beyond what backed enums express?
• Is multi-locale labeling of enum values a real requirement, or is a single label() method sufficient?
• If this is a Symfony→Laravel migration, who owns the shared enum definitions package?

Integration Approach

Stack fit. Treat the bundle as a reference implementation, not a dependency. The transferable concepts are: (a) enum cases resolve their display string via the translation layer with a deterministic key convention, (b) form/input generation derives choices from the enum's own getAvailableValues(), (c) unknown cases degrade predictably rather than throwing in the UI layer.

Migration path.

1. Inventory every enum in the codebase and classify: plain single-value, multi-value, or already a native backed enum.
2. Extract enum definitions into a framework-agnostic package or app/Enums namespace with zero Symfony or Laravel imports — native enum ... : string where PHP allows, keeping string values byte-identical to the legacy constants to protect persisted data.
3. Build the Laravel adapter in-app: EnumTranslator (translation-catalog lookup with a fallback to the raw value), a Rule::enum() validation rule, and a Blade select component.
4. Parity test label output against the Symfony implementation for every case and every supported locale before removing the bundle from any Symfony service definitions.
5. Deprecate the bundle entry in composer.json only after the parity suite is green.

Compatibility. Do not attempt co-installation. The bundle's expected Symfony major (3/4-era) is incompatible with the symfony/* ^6/^7 constraints Laravel 10/11 pulls in; forcing resolution produces a framework-bundle in a Laravel app that will never boot its services. If a Symfony service must keep working during a transition, run the two adapters side by side at the application layer, not in one Composer graph.

Sequencing. Adapter-first, removal-second. Ship the Laravel translator and validation rule behind the same translation key namespace the bundle uses, so catalogs are reused without edits and rollback is a config flag rather than a revert.

Operational Impact

Maintenance — you own it. With one star and zero dependents there is no upstream momentum, no security-response process, and no realistic expectation of a PHP 8.x compatibility patch. Budget a fork-and-vendor line item if any code from the bundle is copied, and record the provenance in the repo.

Support. No community, no issue triage, no documentation beyond a README. Internal ownership must be explicit — name a maintainer for the adapter and the translation key convention, because key drift is the most likely long-term defect.

Scaling. Negligible. Translation lookups are in-memory after catalog load; there is no I/O, no queue, no state. Cost scales with the enum count and locale count only. The one scaling-adjacent concern is translation catalog size if enum labels are loaded per request in an app with many locales — mitigated by Laravel's standard translation caching.

Failure modes to instrument:

• Missing translation key → raw enum value leaking into customer-facing UI. Fail loudly in non-production, fall back to a humanized value in production.
• Case rename → silent corruption of persisted values. Add a test that asserts each case's backing value against a snapshot.
• Divergence between the Symfony form path and Laravel validation during transition, letting invalid values through one door.
• Composer drift if the bundle is left in the graph — an unrelated composer update can break the lockfile resolution.
• MultiEnum semantics mismatch if bitmask combinations are stored as integers and the Laravel adapter treats them as a list.

Ramp-up. Low. A mid-level Laravel developer reproduces this pattern in a day and understands it immediately, because it is idiomatic Laravel rather than Symfony bundle machinery. The expensive knowledge is domain knowledge — which enum values are contractual and which locales matter — not framework knowledge.

Recommendation. Do not adopt. Harvest the pattern, reimplement it as ~150 lines of Laravel-native code against PHP 8.1 enums, and keep the translation key convention so catalogs survive intact.