Formmetadata Laravel Package

Product Decisions This Supports

• Dynamic content / CMS roadmap. If the roadmap includes user-defined content types, configurable entities, or tenant-specific data models, the core mechanism this package demonstrates — attaching form metadata to an entity class via annotations (@Form\Field("text")) so one generic controller can render and persist any entity — is directly roadmap-relevant. It is the difference between shipping one form per entity type and shipping an entity-agnostic admin surface.
• Build vs. buy on admin tooling. Provides a concrete reference for the "generic CRUD/admin panel" decision: N bespoke controllers and templates versus one controller driven by class-level metadata. Useful as a design blueprint even though the code itself is not adoptable on this stack.
• Backlog scope reduction. Every entity that ships with its own hand-wired form is recurring engineering cost. Metadata-driven forms collapse that into annotation/attribute authoring and reframe the planning question from "how many forms can we build this quarter" to "how fast can the business define a new entity type."
• Extensibility surface. Enables internal or third-party teams to register entity types without touching core controllers — a strong enabler for marketplace, plugin, or module-based product lines.
• Multi-tenant schema flexibility gating. Informs decisions about whether tenants can define their own fields, and what the rendering/validation/authorization contract for those fields must be.
• Use cases to validate against: CMS back-offices, internal admin tools over heterogeneous tables, low-code form builders, and import/export tooling that must infer form shape from the domain model.

When to Consider This Package

Consider the pattern — not the dependency — when:

• You have a growing set of entity classes that all need CRUD forms and the per-entity boilerplate is measurably dominating delivery time.
• You want validation, field type, label, and placeholder metadata to live with the domain model rather than be duplicated across controllers, FormRequests, and templates.
• You are deliberately designing a metadata-driven admin layer and want prior art on the annotation-to-form-builder bridge.
• Your codebase is already annotation/attribute-driven and a metadata layer fits existing conventions.

Look elsewhere — or treat this strictly as a design reference — when:

• You are on Laravel. Despite the prompt's framing, this is a Symfony bundle (FormMetadataBundle) targeting the Symfony Form component and Doctrine entity metadata. There is no Laravel integration, no composer require path, and no compatible hook against Eloquent, FormRequests, or Blade. Budget a rewrite, not an install.
• You need a maintained dependency. Zero stars, zero dependents, and no ecosystem signal means no security patch stream, no compatibility guarantees, and no community to absorb bugs. Adopting it as a runtime dependency is a support burden you would own entirely.
• You are on modern Symfony or PHP 8.2+. The @Form\Field docblock-annotation approach reflects the Doctrine-annotations era; doctrine/annotations 2.x removed the annotation reader and Symfony has been retiring annotation config in favor of PHP 8 attributes. The bundle likely does not run unmodified.
• A maintained alternative covers the need. Symfony's Form component with metadata drivers, API Platform, EasyAdmin, or SonataAdmin deliver the same generic-admin outcome with active maintenance; on Laravel, Filament or Nova. Evaluate those first and only build custom if their extension model genuinely blocks you.

Adoption criteria if you proceed anyway: vendor/fork the code, pin it, add tests around the metadata parsing, and confirm the PHP/Symfony versions are ones you are willing to run in production.

How to Pitch It (Stakeholders)

For executives. This is a small, unmaintained open-source bundle that demonstrates how to drive form generation from annotations on your data model, so a single generic controller can handle many entity types. It is not a product we can adopt as a dependency — no community, no dependents, no maintenance — and it does not target our Laravel stack. But the underlying idea is directly useful if our roadmap includes customer-defined content types or configurable admin surfaces. Recommendation: treat it as free prior art, not a purchase. If dynamic content is on the roadmap, we can replicate the pattern on our current framework in a timeboxed internal spike rather than take on an unsupported third-party risk.

For engineering. corleonis/formmetadata maps entity class annotations into Symfony Form builder metadata — the piece that makes generic controllers viable and the real value here. Constraints: Symfony-only, pre-PHP-8-attributes, and no maintenance signal. Ask: does a metadata-driven form layer reduce our per-entity cost enough to justify building and owning it? Recommended validation path: fork the repository, read the annotation-to-FormBuilder mapping (a few hundred lines at most), and prototype the same contract using PHP 8 attributes plus a Laravel-side builder that emits FormRequest rules and Blade/Livewire field components, cached rather than resolved per request. Design in field-level authorization from day one so the generic controller cannot become a mass-assignment bypass. If a timeboxed spike meets the boilerplate-reduction target, we build and own it internally with a documented upgrade cadence; if not, we default to Filament (Laravel) or EasyAdmin/API Platform (Symfony) and close the question.