Laravel Enum Pro Laravel Package

Getting Started

Install the package alongside a PHP 8.1+ runtime (native enums are a hard prerequisite):

composer require lazerg/laravel-enum-pro

Laravel's package discovery registers the service provider automatically. Before writing custom code, open the package's source (vendor/lazerg/laravel-enum-pro/src) and read the base enum class and any trait it ships — this is a thin wrapper, so the public surface is small and worth reading end-to-end in ten minutes. Check the README for a config file and publish it only if you actually need to override defaults:

php artisan vendor:publish --tag=enum-pro-config

Your first use case should be a domain value that already exists as a string column in your database — order status, roles, transaction types. Define it as a backed enum extending the package base:

use Lazerg\EnumPro\Enum;

enum OrderStatus: string
{
    use Enum;

    case Pending   = 'pending';
    case Paid      = 'paid';
    case Shipped   = 'shipped';
    case Cancelled = 'cancelled';
}

Then immediately use it as an Eloquent cast and in a form select. If those two flows work, the package is pulling its weight; if not, you have wasted an hour instead of a day.

Implementation Patterns

Labels live on the enum, not in Blade. The package's main value is letting you attach human-readable metadata to cases via a label() method (or an overridable method name documented in the base class). Keep these adjacent to the case definitions so translations and copy changes are one commit:

public function label(): string
{
    return match ($this) {
        self::Pending   => 'Awaiting payment',
        self::Paid      => 'Payment received',
        self::Shipped   => 'On the way',
        self::Cancelled => 'Cancelled',
    };
}

Eloquent casting. Use the enum directly in $casts. Because it is a backed enum, Laravel's native enum casting handles serialization to and from the DB column with no package involvement — the package only adds helpers on top. This is the safest integration point and the one you should lean on hardest.

Form options. A typical pattern is OrderStatus::options() (or toArray() — confirm the exact name in the base class) returning ['pending' => 'Awaiting payment', ...]. Feed that straight into a Blade @foreach or a Livewire/Inertia select. Centralising this means your validation in: rules, your selects, and your API all agree on the same set.

Validation. Prefer a rule that iterates cases() over a hardcoded string list. If the package ships a EnumRule or similar, use it; otherwise Rule::enum(OrderStatus::class) from Laravel core works on native enums without the package. Do not duplicate the case list in a FormRequest.

API resources and JSON. Native enums implement JsonSerializable, so $request->status will serialize as its backing value automatically. If you want the label in the payload, add it explicitly in the resource ('status' => $this->status->label()) rather than relying on package magic — being explicit about API shape pays off when clients cache responses.

Comparison helpers. Where the package exposes is()/isNot()-style helpers, they read better than === chains in policies: $order->status->is(OrderStatus::Paid). In authorization and state-transition logic this is where the package earns its keep beyond plain enums.

Generation. If an artisan make:enum command is available, wire it into your scaffolding so new enums are born from the base class rather than from php artisan make:enum (Laravel core), which produces a bare enum that won't have the helpers.

Gotchas and Tips

Backed vs pure enums. Most helper methods on packages like this assume a backed enum because options() and values() need something to key on. Pure enums will work for label() but will surprise you elsewhere. If a case has no scalar backing, do not expect toArray() to behave.

Read the base class before trusting the docs. At 43 stars, this is a small, single-maintainer package. The README may lag the code. The source is the contract; verify method names (label, description, options, values, toArray) against the actual trait before spreading them across fifty files.

Casting failures are silent-ish. Laravel returns null for an unmatched DB value when using ?Status nullable casts but throws ValueError for non-nullable ones. Add a data migration or a defensive tryFrom when importing legacy rows — do not assume existing data matches your cases.

Migration column types. On MySQL, backed string enums map cleanly to string/varchar. Avoid the database ENUM type: adding a case then requires a schema migration and locks the table on large datasets. Keep the enum in PHP, the column as varchar.

Translation. If you return __('enums.order_status.paid') inside label(), remember labels are evaluated at call time, not cached — good for locale switching, but it means a missing key returns the key string silently. Add a test that asserts every case yields a non-key label.

Collection grouping. collect(OrderStatus::cases())->keyBy->value is a common idiom; watch out that cases() returns an array on native enums, not a collection, so wrap it first.

Extension points. The likely clean extension surface is overriding the metadata method on individual enums and, if a config exists, customising the base class namespace or the generator stub. Resist forking the package for one missing helper — a trait in app/Enums/Concerns composed alongside the package trait survives upgrades; a fork does not.

Version pinning. Given the low star count and the PHP 8.1 dependency, pin a minor version in composer.json and add a smoke test that instantiates your enums. If the package is abandoned, migrating back to bare native enums is a mechanical delete of the trait use statement and inlining label() — plan for that exit path and the dependency is low-risk.