Form Bundle Laravel Package

Getting Started

First, calibrate expectations: this is not a Laravel package. endroid/form-bundle is a Symfony bundle (its README shows app/AppKernel.php bundle registration, which is pre-Symfony 4 style). composer require endroid/form-bundle will likely resolve in a Laravel project, but nothing will happen: there is no Illuminate\Support\ServiceProvider, no auto-discovery entry, no config/form.php to publish, no migrations. The bundle expects Symfony's Kernel::registerBundles(), a Symfony DI container, and (per the README) Sonata Admin Bundle to actually create forms.

Day-one steps that are actually useful:

1. Read composer.json on the repo before installing. Check the symfony/* constraints and minimum PHP version — an archived bundle like this almost certainly caps at an old Symfony/PHP combination that conflicts with a modern Laravel symfony/http-foundation/symfony/console requirement. Use composer require endroid/form-bundle --dry-run to surface conflicts before you commit.
2. Check the GitHub timeline. The repo is archived — no issues, no PRs, no security patches, zero dependents. Treat any install as a fork-and-own decision.
3. Realistically, the first "use case" is a concept reference, not an integration. Read the bundle's source to see how it models four things: form configuration storage, submission storage, notification-on-submit, and result export. Then rebuild those four in Laravel idioms.

If you genuinely need the Symfony functionality, run it as a separate Symfony app (it needs Sonata Admin anyway) and call it from Laravel over HTTP or a shared queue — don't try to boot a Symfony bundle inside Laravel's container.

Implementation Patterns

What the bundle does in its native Symfony habitat (so you know what to mirror):

• An admin user, via Sonata Admin, defines a form (fields, labels, types) — persisted as configuration, not as a PHP form type class.
• A front-end route renders the configured form and accepts submissions.
• Submissions are persisted as results.
• On submit, notifications are sent.
• Results can be exported.

The Laravel-native translation of that pattern is what you'd actually ship:

forms             id, name, slug, schema (json), notify_to, is_active
form_submissions  id, form_id, payload (json), ip, created_at

• Schema as JSON on a forms table; render fields with a Blade partial that switches on field type (text, email, textarea, select, checkbox).
• Validation: build a rules() array dynamically from the schema and pass it to a FormRequest-style validator (Validator::make($request->all(), $rules)). This is the piece the Symfony bundle gives you for free and Laravel does not — you must map field config → rules yourself.
• Submission storage: FormSubmission::create(['form_id' => $form->id, 'payload' => $request->validated()]).
• Notifications: Notification::route('mail', $form->notify_to)->notify(new FormSubmitted($submission)) — this maps directly onto the bundle's "send notifications when a form is filled in".
• Export: streamed CSV via response()->streamDownload() or maatwebsite/excel. The bundle's export feature is a weekend of work in Laravel, not a reason to install a Symfony bundle.
• Admin: Filament or Nova resource on forms with a JSON/repeater field for the schema; a read-only resource on form_submissions.

If you're forced to integrate the bundle anyway (legacy Symfony service you must reuse): keep it isolated. Deploy the Symfony app, expose POST /forms/{slug} and a results endpoint, and consume it from Laravel with Http::post(). Put the base URL in config/services.php and a typed client class in app/Services/. Do not attempt to share the Doctrine entity manager with Eloquent.

Gotchas and Tips

• Archived + 0 stars + 0 dependents is the headline gotcha. No maintenance, no CVE response, no compatibility work for current PHP. Budget for forking the whole thing if you rely on it.
• Nothing registers in Laravel. If composer require succeeds, you'll get classes you can use but no routes, no container bindings, no config. Symptom: "class not found" or "target [SonataAdminBundle] not found" as soon as you touch its services. There is no php artisan vendor:publish equivalent.
• Sonata Admin is a large dependency tree and pulls its own Symfony components at versions that frequently collide with Laravel's pinned symfony/* packages. Resolve with --dry-run and read the conflict output carefully; you may need --with-all-dependencies and still lose.
• Doctrine, not Eloquent. The bundle's storage is Doctrine entities. There's no migration path to Eloquent models; you'd be running two ORMs in one app, which is not a supported configuration.
• Debugging is Symfony-shaped. Container introspection is bin/console debug:container / debug:router, not php artisan. Don't waste time looking for Artisan commands.
• Config quirks to check in source: look for DependencyInjection/Configuration.php and the extension class to see what config keys it expects and whether defaults assume Sonata. If it hard-references Sonata admin services, the bundle is unusable without Sonata installed.
• Extension points are thin. Expect to override services via the container (services.yaml in Symfony) rather than via Laravel-style bindings or events. There is no event dispatcher integration with Laravel's Event facade.
• Pin the exact version and vendor-lock it if you must install; a floating constraint on an archived repo means you can't reproduce a build six months later.
• The pragmatic tip: steal the data model and the four features (config, store, notify, export), implement in ~2 days with Blade + FormRequest + Notifications + streamed CSV. That's almost certainly cheaper and safer than fighting a Symfony bundle into Laravel.