- Is grossum/extended-form-type a Laravel package?
- No. It is a Symfony bundle named ExtendedFormTypeBundle that hooks into Symfony's Form component and bundle registration lifecycle. Laravel has no bundle registry or equivalent form-type extension point, so the package does not map onto Laravel's Blade, FormRequest, and controller-bound request architecture. Treat it as reference code, not a Laravel dependency.
- Can I install grossum/extended-form-type in a Laravel 10 or 11 application?
- Practically no. The bundle was last released in April 2018 and targets PHP 7.x with Symfony 2.8/3.0-era constraints, which collide with Laravel 10/11's PHP 8.1+ floor and modern symfony/* transitive requirements. Even if Composer resolved, Laravel cannot boot a Symfony Bundle class or load its services.yml. Installation is not a supported path.
- Why does composer require grossum/extended-form-type fail in Laravel?
- Composer resolution typically fails because the package pins old PHP and symfony/form constraints that conflict with the PHP 8.1+ and modern Symfony packages Laravel 10/11 require. The conflict is expected, not an edge case. Forcing resolution would still leave you with a bundle Laravel cannot register or use.
- What does grossum/extended-form-type actually do?
- It provides a reusable extended form type base for Symfony applications, centralizing common form behavior, defaults, and configurable options to reduce boilerplate in custom form types. It works with the standard Symfony Form component and is registered as a Symfony bundle. Its value is in the form-type classes, not in anything Laravel-specific.
- Is grossum/extended-form-type still maintained?
- No. The last release was 2018-04-13, roughly seven years without maintenance, with no PHP 8.x compatibility work and no symfony/form 5, 6, or 7 support. It has 0 stars, 0 dependents, and an ecosystem score around 0.06, so there is effectively no user base or peer support. A single-maintainer 2018 bundle is a supply-chain liability for new projects.
- What are the best Laravel alternatives to ExtendedFormTypeBundle?
- Use Laravel's native primitives: FormRequest classes and custom Rule objects for validation, Blade components or x-form components for rendering, and Livewire or Filament for dynamic collection add/remove behavior. Each capability the Symfony bundle offers has a native Laravel equivalent. Re-implementing the specific behaviors is cheaper and safer than importing a parallel form subsystem.
- Can I use Symfony Form inside Laravel without this bundle?
- Technically yes, because symfony/form is framework-agnostic, but it introduces a second validation and rendering paradigm alongside Laravel's. The bundle layer is dead weight in Laravel since there is no bundle registry to boot it. You would use underlying form types directly and still own the integration and maintenance burden.
- How do I re-implement ExtendedFormTypeBundle behavior in Laravel?
- Start with a timeboxed capability extraction: read the form-type classes and document field composition rules, collection prototypes, validation hooks, and any client-side JS contract. Then map each behavior to Laravel primitives such as FormRequest rules, Blade or x-form components, Livewire for dynamic collections, and custom Rule objects. Build parity tests for field names, nesting, and error keys before removing the package from composer.json.
- Is it safe to use an abandoned 2018 Symfony bundle in production?
- No, it carries severe risk. There is no security triage, no PHP 8.x work, and no support for current symfony/form versions, so unmaintained transitive dependencies become a standing finding in security reviews and SOC2 or ISO questionnaires. Composer resolution failure against Laravel 10/11 is the expected outcome. If you vendor or fork it, assign an owner and a patch SLA for PHP and Symfony upgrades.
- How do I test parity after replacing ExtendedFormTypeBundle with Laravel form code?
- Build a small fixture set that asserts the original behavior: field names, nesting, validation error keys, and any API payload shapes your front end depends on. Run those fixtures against both the reference behavior notes and your Laravel implementation. This protects existing front-end contracts and API consumers while you decommission the package.