Form Generator Bundle Laravel Package

Getting Started

1. Install and register. composer require micayael/form-generator-bundle, then add the bundle to config/bundles.php (Symfony 5.3+) or app/AppKernel.php (older). With zero stars and zero dependents, also copy the source into a fork or pin the exact commit in composer.json before you build anything on it.
2. Read the source before the README. The README is the only spec and the repo has no community validation, so open Resources/config/services.yaml (or services.php) first to learn the exposed service ID, the factory class, and the config key namespace. That is your real API.
3. Find the loader. Look for the YAML/JSON parser (DependencyInjection/Configuration.php and whatever class does Yaml::parse / json_decode). This tells you which schema keys are supported — field name, type, options, label, constraints — and is the file you will extend.
4. First use case: a static, low-risk form. Convert one hand-written FormType (e.g. a contact form or an admin filter bar) into a YAML definition and wire it in a controller. Keep it out of anything user-facing or payment-adjacent until you have tested it against your Symfony version.

Implementation Patterns

• Definition files as first-class assets. Keep forms in config/forms/*.yaml and load them through the bundle's factory rather than constructing FormBuilder by hand. Treat each YAML file like a migration: reviewed, versioned, and diffed in PRs.
• YAML for authored forms, JSON for generated ones. YAML is the right choice for forms a developer edits; JSON is useful when another system (an admin UI, a CMS export, a mobile client) emits form schemas. Do not mix both formats for the same form.
• Controller integration. Expect a pattern like $form = $formFactory->createFromFile('contact.yaml', $data); — wrap this in a thin application-level service (App\FormDefinitionFactory) so the controller never touches the bundle's classes directly. That gives you a single seam to swap or remove the package later.
• Map to Symfony field types explicitly. Define a small allowlist of permitted type values (TextType, ChoiceType, EntityType, …) and resolve them through a map in your own code. This stops arbitrary class names in YAML from being instantiated.
• Validation stays in Symfony. Attach constraints either as a constraints: key the bundle passes to the field options or, more safely, via a FormTypeExtension / class-level Validator on your DTO. Do not trust the bundle's validation handling until you have a test proving constraints fire.
• Testing. Build one functional test per YAML definition: submit valid data, submit invalid data, assert the rendered field names match. These tests are cheap and catch schema drift when the bundle updates.
• Reuse fragments. If the bundle supports includes or partial definitions, keep shared field sets (address block, audit fields) in a _partials/ directory rather than copy-pasting across files.

Gotchas and Tips

• Adoption risk is the headline. 0 stars, 0 dependents, 0 forks of note means no one else is stress-testing this against Symfony 6/7. Check composer.json for the symfony/form constraint; if it caps at 4.x or 5.x, you are adopting an unmaintained dependency. Budget for forking it.
• Treat YAML as code, not data. Never load a definition from user input or an unauthenticated endpoint — YAML parsing plus dynamic type instantiation is a plausible object-injection surface. Restrict definitions to files on disk or a trusted internal store.
• Debugging is manual. There is no documented debug toolbar integration. Dump the resolved definition array (dump($definition)) before it hits FormBuilder; most "field missing" bugs are a schema key the parser silently ignored.
• Silent key drops. Hand-rolled parsers frequently ignore unknown keys instead of erroring. Add your own schema check (a small symfony/config Configuration tree, or a JSON-schema validation step) so typos like optons: fail loudly.
• Extension point is the parser. If you need a new field type or option passthrough, subclass the definition loader rather than patching vendor code — that keeps upgrades to a composer update you can actually run.
• Config cache. If the bundle registers a compiler pass, remember bin/console cache:clear after editing YAML; stale definitions are the most common "it didn't pick up my change" report.
• Have an exit plan. Because the seam is a single factory service, abstracting behind App\FormDefinitionFactory means replacing this bundle with a hand-written FormType registry is a one-file change if the package stalls — which, given its numbers, is the likely outcome.