Form Extra Bundle Laravel Package

Getting Started

Reality check first: this is a Symfony bundle, not a Laravel package. It ships a Symfony Bundle class, form types extending Symfony\Component\Form\AbstractType, and Twig form themes. That means you cannot composer require napas/form-extra-bundle in a Laravel app and expect anything to happen — there is no service provider, no config publish tag, and nothing registers with Laravel's container.

What you can do is treat it as a source of reference implementations to port. For a Laravel developer the realistic entry points are:

1. Read the source before installing anything. Browse the repo on GitHub and look for the conventional Symfony bundle layout:
   • Form/Type/ — the actual field types (this is the payload you care about)
   • Form/DataTransformer/ — model↔view transformations
   • Resources/views/Form/ — Twig form theme blocks (the markup you'd translate to Blade)
   • DependencyInjection/ and NapasFormExtraBundle.php — registration, which you will ignore
2. If you're genuinely on Symfony (legacy app, Symfony 2.x/3.x era), install with composer require napas/form-extra-bundle and register in AppKernel::registerBundles(). Pin the constraint aggressively — the last tagged release is from June 2014, so expect Symfony 2.3–2.8 territory and PHP 5.x.
3. First use case to evaluate: pick the single form type that solves a problem you actually have. Usually these bundles exist to provide things like a country/phone/postal input, a dependent-select, or a custom collection widget. Find that one class, read it top to bottom, and decide whether the logic is worth porting to a Blade component plus a FormRequest.

If you only need one field's behavior, porting 50–100 lines into a Blade component is almost always cheaper than dragging the Symfony Form component into Laravel.

Implementation Patterns

Pattern 1 — Port the form type to a Blade component + FormRequest (recommended). The Symfony type class is usually just: default options, a buildView that sets vars, and optionally a data transformer. In Laravel:

• Move the option defaults into the component's constructor / data array.
• Move buildView vars into the component's public properties.
• Move the Twig theme block into resources/views/components/...blade.php.
• Move validation that lived in the type into a FormRequest rule or a custom Rule object.
• Move the data transformer into a cast on the model or an Attribute accessor/mutator.

Pattern 2 — Livewire for the interactive behavior. If the type does dependent selects, autocomplete, or client-side masking, the Symfony version relies on a JS asset in Resources/public/. In Laravel, reimplement the interaction in a Livewire component with wire:model and updatedFoo() hooks — this gets you server-side reactivity without hand-rolling the JS the bundle shipped in 2014.

Pattern 3 — Symfony Form component standalone (only if the type logic is genuinely complex). You can composer require symfony/form in Laravel and use FormFactory manually. It works, but you inherit the Twig renderer dependency, the translator contract, and a large config surface for what is usually a one-field problem. Reserve this for cases where you're porting many interdependent types at once, and wrap it in a service so the rest of the app never sees Symfony types.

Pattern 4 — Legacy Symfony coexistence. If the app is Symfony and you're migrating toward Laravel incrementally, use the bundle as-is on the Symfony side and mirror the field contract (name, options array shape) on the Laravel side. Keeping option keys identical makes the eventual cutover a validation exercise rather than a rewrite.

Integration tips:

• Reproduce the option contract, not the class hierarchy. Document each option key and default before you start.
• Keep the rendered markup close to the original for the first pass, then restyle — it makes visual diffing during migration trivial.
• Write a feature test per ported field covering: default render, invalid input, and the transformed value after validation.

Gotchas and Tips

• Abandoned since 2014. Zero stars, zero dependents, no releases since June 2014. Treat it as read-only reference code with no security posture, no PHP 8 support, and no compatibility guarantees. Do not add it to a production composer.json you intend to maintain.
• Symfony 2.x idioms everywhere. Expect AbstractType with setDefaultOptions()/getName() rather than configureOptions()/getBlockPrefix(). Those methods were removed in Symfony 3, so even in a modern Symfony app the classes won't instantiate without shimming.
• Twig form themes don't translate mechanically. Symfony's form_div_layout.html.twig block inheritance has no Blade equivalent. You'll rewrite the block rather than convert it; budget accordingly.
• Asset pipeline surprises. Anything in Resources/public/ was written for Assetic or pre-webpack Symfony. Assume the JS is jQuery-era and rewrite it rather than shim it.
• Hidden translator dependency. Form types frequently call $options['translation_domain'] or use trans-style labels. Missing translation keys fail silently in Symfony and will fail more loudly in Laravel — grep for translation_domain and ->trans( before porting.
• Data transformers are the real value. ModelTransformer/ViewTransformer pairs encode the interesting domain logic. Port these first and port them faithfully; the markup is the easy part.
• Debugging on the Symfony side: {{ form_widget(form.field) }} producing nothing usually means the block prefix doesn't match a theme block. Check getBlockPrefix() and confirm the bundle's Twig path is registered under twig.form.resources in config.
• Extension point worth copying: if the bundle exposes a FormExtension with FormTypeExtensionInterface, that pattern maps cleanly to a Blade component's shouldRender() / slot logic — it's the most portable idea in the repo.
• Licensing and attribution. Check the LICENSE file before copying code into a commercial Laravel app; bundles of this vintage sometimes ship without one, which is a legal blocker regardless of technical merit.