Diy Form Bundle Laravel Package

Getting Started

• Install with composer require tourze/diy-form-bundle. The -bundle suffix and the DependencyInjection/ + *Bundle.php files are the giveaway: this is packaged as a Symfony bundle, not a Laravel package. Check composer.json ("type": "symfony-bundle") before assuming anything about auto-discovery.
• In a Laravel app, nothing is auto-registered. Add the bundle's entry point to config/app.php providers (or a small bridge service provider) and bind the services you actually use. If the package only ships a Bundle subclass, expect to instantiate the container extension yourself or run it through a thin adapter.
• First place to look: src/ for Entity/, Repository/, Form/, Controller/ and DependencyInjection/*Extension.php. The extension class tells you which services, parameters, and tags are registered — that is your real API surface, since the README on a 0.0.x package is usually thin.
• Expect Doctrine ORM. The form definitions and submissions are almost certainly entities, so you will need doctrine/dbal plus an ORM bridge (e.g. laravel-doctrine/orm) and a working entity manager before anything runs.
• First use case: define a form (a set of field definitions with type/label/validation), persist it, then render and submit it through the provided form type while storing submissions. Start by building one hard-coded schema and driving it end to end through the form layer before touching the persistence/repository side.

Implementation Patterns

• Schema-as-data. Treat the form definition as rows (form → fields → options), not as generated PHP classes. Build a Symfony FormType at runtime from the field rows, then render the resulting FormView in Blade. This keeps the "DIY" part — user-editable forms — separate from your compiled application forms.
• Repository-driven listing. Use the bundle's repositories for paging forms and submissions. Wrap them in your own query objects/services so a breaking change in 0.0.x only touches one layer.
• Service binding. Inject the bundle's form factory / builder services via the Laravel container. If the package exposes interfaces (look for *Interface.php next to the implementations), bind those rather than the concrete classes so you can swap or mock them.
• Submission pipeline. Persist a submission, then dispatch your own domain event (FormSubmitted) from a listener. Keep business logic out of the bundle's submit path; the package is early and its hooks will move.
• Rendering. Symfony Forms separates the form object from its HTML. Map FormView to Blade partials per field type; keep a resources/views/fields/{type}.blade.php convention so custom field types are just new partials.
• Validation. If the bundle leans on symfony/validator constraints stored on the field rows, mirror them into Laravel's validator for API endpoints so you don't have two divergent rule sets.

Gotchas and Tips

• Version pinning is mandatory. 0.0.2 is pre-release with an empty changelog between 0.0.1 and 0.0.2 — that means a release happened with no documented changes. Pin exact versions ("0.0.2") and review diffs manually before bumping; treat every 0.0.x as potentially breaking.
• Framework mismatch. Symfony bundles assume Symfony's kernel, event dispatcher, and service container semantics. In Laravel you'll typically use symfony/form, symfony/http-foundation, and symfony/event-dispatcher standalone — this works, but do not expect the bundle's autoconfiguration, tagged-service collection, or compiler passes to run for free.
• Container debugging. With the Symfony profiler unavailable, debug by dumping the extension's processed parameters and by resolving services one at a time from the container. If a service is missing, it is almost always an unregistered tag or a compiler pass you didn't execute.
• Doctrine friction. Entity mapping (attributes vs. XML/YAML), proxy directory, and metadata cache need explicit configuration in Laravel. Clear the metadata cache first whenever field definitions "don't update."
• Migrations. Don't let the bundle's entities leak into your default migration path; use a separate entity manager or explicit table prefixes to avoid collisions.
• Extension points. Look for service tags in the DI extension (custom form types, field renderers, submit listeners) — tag-based registration is the standard Symfony extension pattern and is likely how you add your own field types. If the tags aren't wired in Laravel, register those classes manually with the same tag name and build a small collector.
• Test in isolation. Instantiate the form factory and a schema in a unit test without booting Laravel; this is the fastest way to tell whether a failure is the package or your integration layer.