- Can I install idci/extra-form-bundle in a Laravel application with Composer?
- In practice, no. It is a Symfony2 bundle wired through AppKernel, Symfony's dependency-injection container, event dispatcher, and Twig rendering, with no Laravel service provider or facade. Composer will also fail because the bundle pulls Symfony 2.x constraints that collide with the Symfony 6/7 components Laravel already depends on.
- What does IDCI ExtraFormBundle actually do?
- It extends Symfony's Form component with reusable extra form types, form extensions, data transformers, and validation and rendering helpers. The goal is to reduce boilerplate for advanced form fields in Symfony applications. It is registered as a Symfony bundle and is not a standalone PHP library.
- Which Symfony and PHP versions does idci/extra-form-bundle support?
- It is a Symfony2-era bundle, so its composer.json most likely pins Symfony 2.x components and PHP 5.x or early 7.x. Symfony 2 reached end of life in 2018, with extended security support ending in 2019. Check the actual composer.json constraints before making any assumptions.
- Is idci/extra-form-bundle compatible with Laravel 10 or Laravel 11?
- There is no viable direct integration. Laravel 10 and 11 require PHP 8.1+ and modern Symfony components, while this bundle targets the legacy Symfony 2 form stack. You would need to port the concepts or extract the domain logic rather than require the package.
- What are the Laravel alternatives for building dynamic forms?
- Mature Laravel-native options include Livewire, Filament, and JSON-Schema-driven form renderers, plus plain FormRequest validation with Blade views. The right choice depends on whether you need runtime schema definition, conditional field visibility, or multi-step composition. In many cases these options remove the need for a Symfony bundle entirely.
- How do I migrate from IDCI ExtraFormBundle to a Laravel-native implementation?
- Port the concepts, not the code. Run a timeboxed spike to catalog exactly what the bundle does, write a one-page capability spec, then reimplement the schema-to-field-definitions-to-validation-rules-to-render pipeline using Laravel's Validator, FormRequest, and a Blade or Livewire renderer.
- Is idci/extra-form-bundle actively maintained?
- Maintenance signals are weak: roughly five stars, zero dependents, and an anomalous last release date of 2026-08-25 that should be verified. Because it depends on end-of-life Symfony 2, there are no upstream security patches. Treat it as a dormant legacy artifact unless you can confirm otherwise.
- Can I run IDCI ExtraFormBundle as a separate service and call it from Laravel?
- Yes, this is technically possible: stand up a containerized Symfony2 application that exposes form generation over HTTP or a queue and consume it from Laravel. It is workable for a bounded internal tool but inherits an EOL runtime and a second deployment target. It also adds operational overhead for a very small community package.
- Are there security risks when accepting user-defined form definitions?
- Yes. User-supplied field definitions can enable label or attribute injection, XSS in rendered output, and unvalidated dynamic validation rules. The underlying Symfony 2 runtime is also unpatched. Whitelist field types, escape all rendered attributes, validate definitions server-side, and avoid running EOL runtimes in production.
- How should I evaluate idci/extra-form-bundle before committing to it?
- Start with a timeboxed spike: inspect composer.json constraints, confirm whether a test suite exists, and run the bundle in an isolated Symfony2 container. Catalog its form-composition logic and compare it against a one-page capability spec. Then benchmark Laravel-native alternatives such as Livewire or Filament against the same spec before deciding.