Enum Bundle Laravel Package

Getting Started

1. Install with Composer: composer require palabs/enum-bundle. Given the low star count, pin a version in composer.json and vendor-lock it.
2. Register the bundle in config/bundles.php: PaLabs\EnumBundle\EnumBundle::class => ['all' => true]. Symfony Flex may auto-register it — verify, since the recipe is not in the official Flex endpoint.
3. Read the README.md and the src/ directory first. The repository is small enough that the source is the documentation; look specifically for DI extensions, compiler passes, and any Constraint, Form\Type, or Doctrine\Type classes — those tell you exactly what the bundle exposes.
4. Create a backed enum you already need in domain code:

   enum OrderStatus: string {
       case Pending = 'pending';
       case Paid = 'paid';
   }
   

5. First use case: wire it into a form with a ChoiceType where 'choices' => OrderStatus::cases() and 'choice_label' => fn(OrderStatus $s) => $s->name. If the bundle ships an EnumType, use that instead — it saves boilerplate.

Implementation Patterns

Doctrine persistence. If the bundle provides an enum DBAL type, register it in config/packages/doctrine.yaml under dbal.types mapping the type name to the class, then annotate/attribute the entity property with #[ORM\Column(type: 'enum_order_status')] (or whatever the registered name is). Without a bundle-provided type, fall back to a plain string column and cast in the entity accessor — do not rely on the bundle for something you can do in five lines.

Validation. Use the bundle's constraint if present (#[Assert\Enum(...)] style); otherwise Symfony's built-in Choice constraint with choices: OrderStatus::cases() works fine and is one less dependency.

Form integration. Wrap enum-backed fields in a dedicated EnumType (either the bundle's or your own AbstractType), passing the enum class name and mapping choice_value to a short helper (e.g. ->value for backed enums). Centralize this so every enum field in the app behaves identically.

DTO / request mapping. For API payloads, deserialize into an enum by using from()/tryFrom() in the DTO constructor. Wrap from() in a try/catch(ValueError) and convert to a ValidationException — never let a raw ValueError bubble to a 500. This is where a bundle helper (if it exists) is genuinely useful: consistent exception-to-validation mapping.

Repository queries. For WHERE status = :status, pass $status->value for backed enums. If the bundle's DBAL type is in play and well-tested, you can pass the enum instance directly; if you're unsure, do the explicit ->value — it always works.

Testing. Use #[DataProvider] methods returning OrderStatus::cases() so every case is covered as a test input. Assert both the happy path and the rejection path (invalid string) so the validation boundary is explicit.

Gotchas and Tips

• Tiny project, tiny bus factor. 2 stars and 0 dependents means no community validation. Audit the src/ before production use; if it's a thin wrapper, copy the useful classes into your app instead of depending on it. Your code will be more maintainable.
• DI extension naming. Symfony bundles expect an extension class named <BundleName>Extension in DependencyInjection/. If the config tree isn't exposed or is broken, you'll silently get no services. Run bin/console debug:container --tag=<any tag the bundle uses> to confirm services are registered.
• DBAL type aliasing. Doctrine's Type::addType() in a bundle constructor is deprecated in newer DBAL; prefer YAML config. If the bundle uses the old approach, you'll see deprecation notices — don't suppress them.
• Backed vs unit enums. Decide early which you need. Backed enums (string/int) persist and serialize cleanly; pure unit enums require name mapping and are a common source of "value not found" bugs when refactored.
• ->name vs ->value. name is the case identifier, value is the backing scalar. Mixing these up in a DB column is a silent data-corruption bug — add a unit test asserting $case->value for every case.
• Serialization. json_encode(OrderStatus::Paid) yields "paid" for backed enums, but unit enums won't serialize at all. Add a normalizer if the bundle provides one; otherwise handle it in your serializer config.
• Config quirks. With no config/packages/palabs_enum.yaml, the extension may fail if it requires a mandatory node. Run debug:config palabs_enum after install to catch this immediately, not in staging.
• Extension points. The likely useful ones are: custom form type, custom validator, and Doctrine type. If none of these exist as overridable services, treat the bundle as read-only convenience and expect to fork if you need behavior changes.
• Upgrade risk. Because the project is unmaintained-looking, treat any major Symfony upgrade as a potential break. Keep the dependency behind a small adapter layer (a single EnumHelper service in src/) so removing the bundle is a one-file change rather than a repo-wide find-and-replace.