- What is fsi/form-extensions-bundle used for?
- It is a Symfony bundle that provides reusable form extensions and form types for common UI patterns, layered on top of symfony/form rather than replacing it. It also ships a Twig form theme and front-end assets for richer collection widgets such as add, remove, reorder and picker-style inputs. The goal is to cut repetitive form configuration and custom glue code, mainly on admin and back-office screens.
- Is fsi/form-extensions-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. There is no bridge to Laravel's validator, Blade, Livewire or Inertia, and its service wiring assumes a Symfony kernel and container. For a Laravel codebase, treat it as out of scope unless you only want to read it as a reference implementation.
- How do I install and register fsi/form-extensions-bundle?
- Install it with Composer, register the bundle in config/bundles.php, then import the bundle configuration. Publish or install the front-end assets into your own build, whether that is Webpack Encore, Vite or importmap, and append the bundle's form theme to twig.form_themes. Finally load the JavaScript on the pages that use the collection widgets. A developer already fluent in Symfony forms should get through this in roughly half a day.
- Which Symfony and PHP versions does fsi/form-extensions-bundle support?
- The current guidance targets Symfony 5.4, 6.x and 7.x with Twig 3 on PHP 8.x, but you should verify the exact matrix against the package's composer.json and any CI configuration. A recent release tag does not by itself prove compatibility across every minor version. Build a written compatibility matrix covering Symfony version, PHP, asset pipeline and JS runtime before adopting.
- What does fsi/form-extensions-bundle add over Symfony's native CollectionType?
- Symfony's CollectionType with allow_add, allow_delete and a prototype already covers basic add and remove behaviour, so the bundle's value is mostly in the reorder and picker-style widgets plus the packaged Twig theme. Whether that is worth a dependency depends on how many of those widgets you actually need. If you only need two or three, copying the markup and JavaScript inline is often cheaper than adopting and maintaining the bundle.
- How do I set up the Twig form theme and assets from fsi/form-extensions-bundle?
- Append the bundle's theme to the twig.form_themes configuration so its templates take precedence for the affected form types. Install or publish the CSS and JavaScript through your own asset build rather than relying on CDN links. Check which third-party libraries the theme pulls in, because the front-end assumptions skew toward jQuery and jQuery UI era tooling.
- Will fsi/form-extensions-bundle conflict with Symfony UX or Stimulus?
- It can. The bundle's front-end layer predates Symfony UX and Stimulus conventions, so you may end up running a parallel jQuery runtime on the same page. That is a real cost rather than a footnote, especially if you intend to port the behaviour to Stimulus later. Prototype one form and inspect the rendered markup and loaded scripts before committing.
- Is fsi/form-extensions-bundle actively maintained?
- Maintenance is effectively single-vendor, from FSi Open in Poland, and attention is split across a large bundle family. The public adoption signal is weak, with only a handful of stars and no listed dependents, which means no third party has visibly validated it in production. Verify the release date against commit history and check the issue-response latency over the last twelve months.
- How should I use fsi/form-extensions-bundle safely in production?
- Pin an exact version in composer.json and mirror the package to an internal Satis or private Packagist repository so an upstream deletion is not an outage. Migrate one low-risk admin form first, diff the rendered markup against your current output, and keep the legacy theme registered behind a feature flag so rollback is a config change. If more than one application depends on it, plan for a vendor fork as the default operating model.
- What are the alternatives to fsi/form-extensions-bundle for collection widgets?
- For basic add and remove, Symfony's CollectionType with allow_add, allow_delete, a prototype and a DataTransformer covers most needs. For drag-and-drop reordering, a small amount of custom JavaScript or a Symfony UX component is usually less risky than adopting a lightly adopted bundle. There is no Laravel equivalent to evaluate here, because Laravel has no symfony/form component to extend.