- How do I install cerbero/laravel-enum in a Laravel application?
- Install it with Composer using composer require cerbero/laravel-enum. It requires PHP 8.1 or newer with native backed enums, so no extension or extra configuration is needed. Adoption is per enum: add the package trait (or extend the base enum class) to the enums you want to enhance, then remove any hand-rolled label, options, or toSelect helpers. There is no service provider, migration, or config file to publish, so the whole change set stays in your domain layer.
- Which PHP and Laravel versions does cerbero/laravel-enum support?
- The package targets PHP 8.1+ backed enums and Laravel 9, 10, and 11-era applications. It is not usable on PHP 8.0 or earlier because those versions have no native enum support at all. Because convenience packages that track Laravel majors tend to ship breaking majors, pin a version and budget for an upgrade every one or two Laravel majors. Check the maintainer's published support policy before committing to a long-lived Laravel version.
- Does cerbero/laravel-enum replace native PHP enums or Laravel's Rule::enum validation?
- No. It is a thin userland layer that composites behaviour onto your existing native backed enums via a trait, so the underlying enum cases and backed values are unchanged. Laravel's Rule::enum validation, native Eloquent enum casts, and backed-enum route binding still work exactly as before. The package's value is ergonomics such as labels, metadata, membership helpers, and select options, not capability you cannot get from the framework. That means the buy-versus-build decision is really about whether the ergonomic gain justifies an extra dependency.
- How do I add labels and descriptions to enum cases with cerbero/laravel-enum?
- You add the package trait to your enum and define the label or description metadata the package expects, rather than hand-writing a label() match expression per enum. Helper methods then expose those labels and descriptions consistently across your codebase. Because these helpers are presentation sugar, treat them as display-layer concerns and keep the backed value as your serialization contract. This keeps labels out of API payloads and database columns while still giving you a single source of truth.
- Can I use cerbero/laravel-enum enums with Eloquent model casts?
- Yes, because the enums remain native backed enums, so Laravel's built-in enum casting continues to work unchanged. The important thing to verify in a spike is that serialization stays identical to a plain backed enum, meaning toJson and toArray on models still emit the backed value and not a helper-derived array. Keep ->value as the serialization contract and do not let helper methods leak into JSON responses. Run your existing test suite against a model that already uses an enum cast to confirm round-tripping is unaffected.
- What helper methods does the cerbero/laravel-enum trait provide?
- The trait adds case lookups such as fromName and tryFromName, comparison and membership helpers such as is, isNot, in, and notIn, and collection-style transforms such as values, names, toArray, and cases. It also provides metadata and attribute access for labels and descriptions, plus selection-list helpers for building form options. These are convenience APIs layered on top of native enum behaviour, so you can adopt them incrementally. Codify which helpers your team standardises on so the codebase does not mix native cases() calls with package helpers that behave subtly differently.
- Is cerbero/laravel-enum safe to use in production with Octane or long-running queue workers?
- The package has no service provider, middleware, or framework plumbing, so it does not hook into the worker lifecycle itself. The risk to check is whether its lookup helpers cache case data statically, since a deploy that adds or renames enum cases could then serve stale data in a long-running worker until restart. This is the same worker-restart discipline you already apply to config and route caching, so it is manageable. Validate the behaviour in a staging spike under Octane before rolling it out broadly.
- How do I build a select dropdown or validation rule from a cerbero/laravel-enum enum?
- Use the selection-list and toArray helpers to turn an enum into a key-value structure you can pass straight to a Blade select or a JSON response for a front-end component. For validation, pair the enum with Laravel's Rule::enum or Rule::in using the values helper rather than duplicating a list of allowed cases. This keeps the form options and the validation rule derived from the same enum, so they cannot drift apart. It also removes the stringly-typed arrays that usually get scattered across controllers and form requests.
- What happens if cerbero/laravel-enum is abandoned or unmaintained?
- The package is MIT licensed with a small code surface and effectively zero recorded dependents, so vendoring or forking it is entirely practical. The worst-case removal is a mechanical refactor in the domain layer rather than a data or infrastructure migration, because backed values and database columns stay identical. Before adopting, count the call sites that would need to change and plan the fork contingency rather than improvising it later. Treat it as a bus-factor-one dependency and make the exit cost explicit in your adoption decision.
- What are the alternatives to cerbero/laravel-enum?
- The main alternative is plain native backed enums combined with Laravel's built-in Rule::enum validation and native enum casts, which cover most day-to-day enum needs without an extra dependency. Other community enum packages offer overlapping label and select-option helpers, so compare method signatures and maintenance activity before choosing. For teams already standardised on native enums, a small internal trait may be the cheapest option and keeps the exit cost at zero. Adopt a package only where the ergonomic gain is real, and consider doing so selectively rather than universally.