- Is micayael/form-generator-bundle a Laravel package?
- No. The package name and its Spanish description indicate it is a Symfony bundle, not a Laravel package. It is built around Symfony's dependency injection container and the symfony/form component. A Laravel application cannot consume it as-is without an adapter and a bundle-registration shim.
- How do I install micayael/form-generator-bundle with Composer?
- You can run composer require micayael/form-generator-bundle, but the package expects a Symfony application with FrameworkBundle and symfony/form installed. There is no Laravel package-discovery entry, no service provider, and no config publish tag. In Laravel you would need to register its services manually or write a thin Illuminate service provider. Expect to pull in Symfony Form, options-resolver, and property-access as transitive dependencies.
- Does this package work with Laravel 10 or 11?
- Not out of the box. There is no Laravel facade, configuration file, or auto-discovery support, and compatibility with PHP 8.2 or Laravel 10 and 11 is unverified. The integration path would be a custom adapter that bridges Symfony constraints to Laravel's validator and replaces Twig rendering with Blade. Treat any Laravel support as something you build, not something the package provides.
- How do I render forms from YAML or JSON in Laravel using this bundle?
- The bundle renders through Symfony Form and Twig form themes, which clashes with Laravel's Blade stack. You either introduce Twig alongside Blade, creating two templating engines and component libraries to maintain, or consume only the schema layer and hand-write Blade rendering. The second option discards a meaningful share of the package's value but avoids the dual-engine maintenance tax.
- Can I use only the YAML or JSON form definitions without Symfony Form?
- In theory the declarative schema layer is the most reusable part, since admin-configurable or tenant-specific forms are a real gap in stock Laravel. In practice the package is wired through Symfony's container and its generator services, so isolating the parser means reading internals and reimplementing rendering and validation. That work is roughly a 200-line native capability if you build it directly in Laravel.
- Is it safe to generate form fields from untrusted YAML or JSON configuration?
- Config-driven type instantiation is an architectural risk because the config file becomes an executable specification. If field types map to arbitrary class names or options pass through unvalidated, you have a deserialization and injection surface. Any adoption requires a strict allowlist of permitted field types and options, plus validation before instantiation.
- Is micayael/form-generator-bundle actively maintained?
- Signals are weak: zero stars, zero dependents, a single author, and no visible test suite or CI configuration. Zero dependents means no production consumers have battle-tested nested collections, conditional fields, file uploads, CSRF, or i18n. Treat it as a reference implementation to study rather than a dependency to adopt.
- What are good Laravel alternatives for database-driven or configurable forms?
- Build a native YAML or JSON form schema rendered with Blade partials and validated with Laravel Validator rules; it is a small, bounded piece of work. If you want batteries included, look at Livewire or Filament form builders, which already handle dynamic fields inside the Laravel ecosystem. Either path avoids two DI containers, two templating engines, and two validation models.
- How much effort does it take to adapt a Symfony bundle like this to Laravel?
- Realistically one to three weeks of engineering to reach a working spike, plus ongoing cost to track two ecosystems and Symfony major-version changes. You also need to bridge Laravel's validator to Symfony constraints and solve rendering with Twig or a custom Blade renderer. A native Laravel implementation of the same schema capability is closer to three to five days.
- Does the bundle support current Symfony majors and PHP 8.2 or newer?
- Symfony Form has breaking changes across major versions, and there is no signal that this package tracks them. PHP and Laravel version compatibility is unverified, so check the composer.json constraints before considering any use. Lack of dependents also means version drift is unlikely to be reported or fixed quickly.