Form Bundle Laravel Package

Product Decisions This Supports

• Entity-selection UX pattern. The core decision this touches is: when a form must reference a related record (a customer, a product, a user), do we render a <select> populated with every candidate, or a plain identifier input backed by client-side search/autocomplete? entity_id encodes the second choice. That matters once candidate sets exceed a few hundred rows — a full EntityType choice list becomes a payload, memory, and usability problem.
• Build vs. buy for a single form type. Honest scoping: the entire capability is a FormType plus a DataTransformer (id ⇄ entity), roughly 30–60 lines. Adopting a dependency here is buying a rounding error. The PM decision is really "do we want a third-party in the form layer for something we'd own in an afternoon?"
• Wire-format vs. domain-object boundary. Using an id-based field keeps the submitted value a scalar (int/UUID) rather than an ORM object graph, which is relevant if the same form is later reused behind a JSON endpoint or if the persistence layer changes.
• Legacy modernization scoping. If it already appears in a Symfony codebase, it's a concrete item on an upgrade checklist — a candidate to inline and delete during a framework bump rather than port forward.
• Platform fit check. Despite the "Laravel/PHP" framing, this is a Symfony bundle (DI extension, service definitions, form theme assumptions), not a Laravel package. That alone kills it as a greenfield option for a Laravel roadmap and constrains it to existing Symfony estates.

When to Consider This Package

Adoption criteria — all of these should hold:

• You are on an older Symfony line that matches the bundle's composer.json constraint (this package's era is Symfony 2.x; verify before anything else).
• You already use it and the cost of touching the form layer outweighs the cost of carrying it.
• You genuinely need id-input-plus-autocomplete rather than a choice list.

Reasons to look elsewhere:

• Laravel. Nothing here applies. Use an Eloquent-backed select, a Blade/Livewire search component, or a small custom rule + controller.
• Modern Symfony. EntityType with an autocomplete endpoint, or a maintained Symfony UX autocomplete solution, is better supported than a 64-star bundle with zero dependents — that's no ecosystem validation at all.
• Maintenance signal. Score 2.21 against an opportunity score of 8.36 reads as "real niche, weak artifact." Treat the idea as validated and the code as disposable.
• Security. Any package of this shape typically resolves a submitted id with a bare lookup. Authorization ("can this user reference that customer?") and existence validation must be yours regardless of what you adopt. Do not assume the bundle provides them.

How to Pitch It (Stakeholders)

To executives: This is not a platform decision, it's a form-field convenience. The underlying idea — let users search for a related record instead of scrolling a dropdown of thousands — is worth adopting. The specific dependency is not: it is small, effectively unmaintained, has no downstream users, and carries more carrying-cost than the code it replaces. Recommendation: reproduce the pattern in-house and skip the dependency.

To engineering: The problem is real and the solution is well understood: a form field that accepts an identifier plus a data transformer that maps it to an entity, with search handled client-side against a lightweight lookup endpoint. We should own that code — it's tens of lines — and explicitly own the two things third-party versions of this pattern usually omit: existence validation and per-record authorization. If we're on an older Symfony app already using the bundle, keep it for now and add "inline and remove" to the next upgrade's scope; do not port it forward.