Enum Laravel Package

Technical Evaluation

Architecture fit. greg0ire/enum is a pre-PHP 8.1 workaround that emulates enum semantics using class constants plus validation helpers. It fits only in the narrow band of applications still running PHP 7.x or early PHP 8.0, typically Laravel 5.8–8.x. On any modern Laravel baseline (9.x on PHP 8.0+, 10.x/11.x on PHP 8.1+), the package is functionally redundant: native enum types, backed enums, and enum_exists() supersede it entirely. Treat it as a legacy compatibility shim, not a strategic dependency.

Integration feasibility. Technically low-effort. It is a Composer library with a minimal API surface (no service provider, no framework coupling), so adoption is a one-line require plus refactoring call sites to use its base class/validation helpers. There is no first-party Laravel integration to evaluate, and no facade, config, or migrations. The main integration work is not wiring but governance: deciding where enum semantics live and preventing new adoption once the codebase moves to PHP 8.1+.

Technical risk. The dominant risks are lifecycle and provenance, not runtime behavior:

• License ambiguity (NOASSERTION). This is the highest-severity flag. A legal review is required before shipping; if the upstream license cannot be confirmed, vendor or replace rather than depend.
• Unmaintained trajectory. Last release 2023-05-24 — after PHP 8.1 shipped — strongly suggests the package is in maintenance/legacy mode. Expect no fixes for future PHP deprecations or edge cases.
• Unknown repository link. No upstream visibility means no ability to assess commit activity, security posture, or issue backlog. Supply-chain review should be manual.
• Low adoption signal. 45 stars indicates a small user base; community support and third-party validation are minimal.
• Semantic drift risk. Emulated enums are not type-safe at the language level, so invalid values can reach persistence layers and boundaries, unlike native enums.

Key questions.

1. What PHP and Laravel versions does the target application actually run, and is there a funded roadmap to PHP 8.1+?
2. Has legal confirmed the license terms, and is the package safe to redistribute/vendor?
3. Where is the canonical upstream repo, and is there a maintained fork we should track?
4. Are enum values persisted (DB columns, queues, APIs, analytics)? If so, what is the migration plan to preserve stored values?
5. Who owns enum refactoring — platform team or each product team?

Integration Approach

Stack fit. Acceptable only for legacy PHP 7.x / Laravel ≤8 services. Reject for greenfield or any service on PHP 8.1+, where native enums should be mandated.

Migration path. Run a two-step program rather than a direct adoption:

1. Contain. Wrap existing enum usages behind a thin internal interface/abstract base (e.g. App\Support\Enum) so call sites do not reference the third-party class directly. This is the critical step for reversibility.
2. Convert. Replace the shim with native backed enums behind that same interface, using from()/tryFrom() for validation and mapping persisted scalar values via a serialization adapter.
3. Remove. Once all services are on PHP 8.1+, drop the Composer dependency and delete the abstraction if it adds no value.

Keep the dependency pinned to an exact version and vendored (or mirrored) if license review permits, so an upstream disappearance does not break builds.

Compatibility. Verify Composer constraints against the target PHP minor and test against the oldest supported Laravel in the fleet. Because the package touches class-constant patterns, check autoloader behavior under optimized/classmap-authoritative autoloading, and validate that enum values survive json_encode, queue serialization, and Eloquent casting without change.

Sequencing. Legal review → upstream provenance audit → contain behind interface → native enum conversion per service → dependency removal. Do not convert and remove in the same release; keep one rollback-capable step between persistence changes and dependency deletion.

Operational Impact

Maintenance. Near-zero upstream maintenance expected. The real burden is internal: the abstraction layer and conversion program must be staffed. Budget explicitly; an unmaintained shim tends to linger for years if not scheduled.

Support. No vendor support and a small community. Escalation path is "read the source" — acceptable only because the source is tiny. Plan for internal ownership of any fork.

Scaling. Runtime cost is negligible: class constants and validation are effectively free versus native enums. No memory, throughput, or infrastructure implications. This package is not a scalability concern in any dimension.

Failure modes.

• Silent invalid values — unvalidated constants reaching the DB or external APIs; mitigated by centralizing validation in the abstraction.
• Persistence drift — serialized enum representations changing between the shim and native enums; mitigated by an explicit value-mapping test suite.
• Supply-chain break — upstream repo or Packagist entry disappearing; mitigated by pinning and vendoring.
• PHP upgrade breakage — future deprecations with no patching path; mitigated by the mandated conversion deadline.
• License exposure — unresolved terms surfacing at audit or M&A; mitigated by legal sign-off before merge.

Ramp-up. Engineers can learn the package's API in under an hour; it is small and idiomatic. The non-trivial ramp-up is organizational — aligning teams on the native-enum standard, reviewing call sites, and validating persisted data. Plan for a short technical onboarding and a longer governance runway.