Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Extra Form Bundle

Extra Form Bundle Laravel Package

idci/extra-form-bundle

IDCI ExtraFormBundle extends Symfony’s Form component with additional form types and helpers, making it easier to build richer forms with less custom code. It integrates cleanly into Symfony applications and reduces boilerplate for common advanced form fields.

View on GitHub
Deep Wiki
Context7

Symfony2 bundle that expand existing FormType feature to allow a dynamic form generation

Frequently asked questions about Extra Form Bundle
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.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
robertmarney/lara-hierarchial-collections
simonschaufi/rule-doc-generator
emissaoja/emissaoja
blackbricksoftware/gravityforms-civicrm-form-processor
al-rahabi/fancy-crud
jinas/dhivatar-component
mltstephane/laravel-quality
bernskiold/laravel-talentlms
bernskioldmedia/laravel-form-architect