- Can I use neutron/form-bundle in a Laravel application?
- No. neutron/form-bundle is a Symfony bundle that registers through Symfony's Bundle and FrameworkBundle machinery, so it has no service provider, no facade, no config/form.php, and no publishable assets. Composer may resolve it inside a Laravel project, but nothing usable will boot. On a Laravel target this package is a pattern source, not a delivery dependency.
- How do I install neutron/form-bundle with Composer?
- You would run composer require neutron/form-bundle and then register the bundle in a Symfony kernel. The package's constraints target the Symfony 2.x era, so expect Composer 2 on PHP 8.1+ to fail or require a fork and a constraint rewrite. There is no Laravel auto-discovery step to rely on.
- Which PHP and Symfony versions does neutron/form-bundle support?
- The repository reflects Symfony 2.x-era conventions: AppKernel-style bundle registration, old Composer constraints, and likely PHP 5.x code. It does not target Symfony 5.4, Symfony 6, or PHP 8.1+. Bringing it to a modern stack is a rewrite rather than a version bump.
- Why does neutron/form-bundle install but do nothing in Laravel?
- Because Laravel integration depends on package discovery, a service provider, container bindings, Blade directives, and publishable configuration, and this bundle ships none of those. It only knows how to hook into Symfony's kernel and container. Once installed in Laravel it simply sits inert in the vendor directory.
- What are the Laravel alternatives to neutron/form-bundle?
- For the same goal in Laravel, use Livewire, Livewire-style Blade components, Inertia with a schema-driven form renderer, or Filament for admin-style forms, paired with Laravel's own validation. The worthwhile idea to copy is a server-owned, declarative form schema that a thin client renders. Map that pattern onto your stack instead of vendoring this code.
- Does neutron/form-bundle require JavaScript or a specific client runtime?
- Yes, despite the zero-JavaScript promise. That promise rests on sibling neutron bundles plus an AngularJS 1.x-era client runtime that reached end-of-life in December 2021. The server emits markup and attributes that this specific client interprets, so breakage is invisible at the PHP layer and only surfaces in the browser. You would have to vendor and pin those siblings as well.
- Is neutron/form-bundle maintained and safe for production?
- Treat it as abandoned. The repository shows a decade-old lineage, around 11 stars, and zero dependents, which means no production corpus, no issue threads, and no community forks to learn from. The MIT license is clean, but assume zero upstream support and no security responsiveness, including PHP 5-era code and old transitive dependencies with known CVEs. It is not a responsible production dependency.
- Can I fork neutron/form-bundle for a modern Symfony or Laravel project?
- Legally yes, since the MIT license leaves forking unencumbered. Practically the fork is a rewrite: modernize constraints, add type hygiene, replace the end-of-life client runtime, and rebuild the view-layer contract. Reproducing the server-defined schema to rich client form behaviour on a maintained stack is usually cheaper than reviving this code.
- What does neutron/form-bundle actually do?
- It integrates the Neutron form component into Symfony and offers a declarative, object-oriented API for defining, validating, and rendering forms. Features include reusable form definitions and field types, Symfony service configuration, built-in validation with clear error handling, Twig rendering helpers, and an extensible architecture for custom components. The design goal is reusable form logic with explicit configuration so complex forms stay maintainable.
- How do validation and Twig rendering work in neutron/form-bundle?
- Validation is built into the form component with structured error handling, and Twig helpers render consistent markup for your fields. Both depend on symfony/form, symfony/framework-bundle, and Twig being present inside a booted Symfony application. In Laravel none of those assumptions hold, so you would reimplement the same behaviour with Laravel validation and Blade components.