Dynamic Form Bundle Laravel Package

Getting Started

Treat this as a library you borrow from, not a bundle you install. It targets Symfony's Form component (symfony/form), and the *Bundle class plus DI extension only do anything inside a Symfony kernel — inside Laravel they are dead weight. The realistic first step is:

composer require symfony/form symfony/validator wemxo/dynamic-form-bundle

Then read, in this order:

1. composer.json — the Symfony version constraint tells you which symfony/form major you must hold. This is the single biggest compatibility risk; a 2025 release date does not mean it tracks Symfony 7.
2. src/ — find the class that takes a config array and produces a FormType/FormBuilder. That one class is the whole package for your purposes; everything else is wiring.
3. tests/ and the README example config — they are the only reliable documentation at 10 stars.
4. The DI extension (DependencyInjection/*Extension.php) — useful as a map of which services the factory needs injected.

First use case: a per-tenant or per-entity schema stored as JSON (field name, type, options, constraints), passed to the factory at request time to build a form, submitted, validated, and persisted. Get that loop working in a plain artisan command or a single controller before touching Blade rendering or Eloquent.

Implementation Patterns

• Schema as data, cached. Build the form type from a config array loaded from DB/JSON, and cache the compiled result per schema hash. Rebuild only when the config row changes — dynamic form construction is not free and you do not want it in a hot loop.
• Thin service provider, no bundle boot. Bind the factory in a Laravel provider with its constructor dependencies resolved manually (ValidatorInterface, FormFactoryInterface, event dispatcher). You are doing the container's job that Symfony's extension would normally do — copy the argument list from the extension class.
• Submit explicitly. Symfony's handleRequest() needs a RequestStack and expects Symfony's request shape. In Laravel, call $form->submit($request->all(), 'PATCH' === $request->method()) and handle $form->isValid() yourself. This is actually cleaner than the Symfony path and worth standardising on.
• Bypass views entirely. createView() requires a form renderer (Twig-backed). If you do not want the Twig bridge, iterate $form->all() and render each child's name, type, and options into your own Blade partial. You lose form themes but keep full control of markup.
• Validation split. Symfony constraints in the config or Laravel rules — not both. Translating NotBlank/Length/Regex from the config into a Laravel Validator rule array is usually less work than wiring symfony/validator into Laravel's error bag, and it keeps error messages in one place.
• Schema-to-persistence. If dynamic fields become columns, generate migrations from the same config and gate destructive diffs behind a review step; if they become JSON, keep a separate cast/accessor layer so the form config and the stored shape cannot drift.
• Test with fixture configs. One Pest/PHPUnit test per field type, asserting the built form's children and the validation outcome. This is cheap and is your real regression suite, since the package's own tests will not cover your configs.

Gotchas and Tips

• Bundle lifecycle is a red herring. No register()/boot() for the bundle, no config/packages/*.yaml. If a README step says "enable the bundle", skip it.
• createView() will throw without a renderer. Plan for manual rendering or pull symfony/twig-bridge deliberately — do not discover this at render time.
• CSRF. Symfony's form CSRF extension expects Symfony's token storage. Disable it (csrf_protection => false) and rely on Laravel's VerifyCsrfToken middleware; otherwise you get silent invalid-submit failures.
• Config-supplied type strings are an attack surface. If the config is user- or tenant-editable, an unchecked type value can be used to instantiate arbitrary form type classes. Whitelist allowed types before handing the config to the factory.
• Field names flow into validation rules, SQL identifiers, and request keys. Sanitise to a strict [a-z_][a-z0-9_]* pattern at config-write time, not at build time.
• 10 stars / 0.05 score means no safety net. Pin the exact version in composer.json, read src/ end to end before trusting it, and be prepared to vendor the ~few hundred lines that matter. If the API surface you actually use is one factory method, copying it into app/Support/ is a legitimate move and removes the dependency risk entirely.
• Extension points to prefer: subclassing the package's form type, or wrapping the factory in your own DynamicFormBuilder service. Do not patch vendor code — you will not get upgrades, and there are not going to be many.
• Debugging tip: when a form builds but submits empty, dump $form->getExtraData() — it usually means your field names in config do not match the request keys (dot notation vs. nesting for compound fields).