Entity Hidden Type Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged: poor, with a stack mismatch up front. glifery/entity-hidden-type-bundle remains a Symfony2 bundle, not a Laravel package. 2.1.0 adds one-to-many support to the Form type and data transformer; it does not add a Laravel integration path. There is still no Form component, bundle kernel, or Doctrine entity manager in a standard Laravel stack, so the package's core mechanism has no host to attach to. In Laravel the equivalent capability remains a hidden Blade input containing the key (or a delimited set of keys), plus route model binding, a FormRequest rule (exists:table,id / array validation with distinct), and an explicit findOrFail with a policy check — roughly 20–40 lines of first-party code for the single case, perhaps 60 for the collection case.

Integration feasibility — very low, slightly worse for the new feature. Pulling this in would still mean adding symfony/form, symfony/http-kernel, symfony/dependency-injection, and Doctrine ORM to a Laravel application purely to obtain an ID→entity transformer. The 2.1.0 release notes mention only the one-to-many PR; there is no stated change to PHP or Symfony constraints and no changelog entry indicating a modernization. Absent evidence to the contrary, assume the same 2017-era constraint floor (PHP 5.x/7.x, Symfony 2.3–2.8) and the same use of APIs removed in Symfony 3/4 (setDefaultOptions, getName). A minor version bump with a feature PR is the least likely release shape to carry a compatibility refresh.

Technical risk — high, with a new dimension from collection hydration. Still a single-maintainer, low-adoption package; 2.1.0 is a community-contributed feature merged from a third-party fork (tkuska), which is a positive maintenance signal but not a governance or support commitment — there is still no CI signal, security disclosure path, or published support policy visible in the release data. The IDOR surface is unchanged in kind and broader in scope: with one-to-many, the client-supplied payload now carries a set of identifiers, so the resolver must authorize every element, not just one. A partial-authorization bug (validating the first ID, trusting the rest) is a realistic and quiet failure. Collection support also introduces serialization ambiguity — delimiter, JSON array, or repeated field — which the assessment cannot resolve from the release note alone and which materially affects both validation and tamper resistance.

Key questions.

• Does the target application even have a Form component and an ORM entity graph, or is this a CRUD app where Eloquent + policies cover the case?
• Is the "hidden entity" pattern a real requirement, or a workaround for not wanting to write a scoped query in the controller?
• What is the ID type (integer, UUID, composite)? Legacy implementations typically assume a scalar, which fails silently on UUIDs — and 2.1.0's collection support makes the scalar assumption harder to reason about, not easier.
• New: What wire format does 2.1.0 use for the one-to-many payload, and is it stable/documented? An undocumented delimiter format is a compatibility and validation hazard.
• New: Does the one-to-many path authorize each member of the collection, and does it fail closed on a partially-valid set?
• Who owns the fork when the upstream goes dark permanently (it already did once, and 2.1.0 does not establish a durable maintainer bench)?
• What is the migration cost to Symfony 6/Laravel 11 if the bundle is kept as a transitive dependency?

Given a score of 0.53 and zero dependents, the opportunity signal (4.89) still reflects whitespace in this capability, not viability of this package as the vehicle. The 2.1.0 feature narrows the capability gap slightly for genuine Symfony 2.x shops; it does not move the Laravel verdict.

Integration Approach

Stack fit — none for Laravel, unchanged. Recommend rejecting the dependency outright. If the team is maintaining a legacy Symfony 2.x application, the bundle fits its era and installs cleanly, and 2.1.0 is the release to pin if one-to-many hidden references are needed; that is the only scenario where adoption is defensible, and it should be time-boxed to the life of that application.

Migration path — reimplement, do not port. The reusable asset is the transformer logic, not the bundle. In Laravel: a hidden input carrying the key (or a JSON/CSV array of keys), validated with exists:table,id or array + distinct + per-element exists, resolved via route model binding or an explicit scoped query, followed by a policy/authorize() gate before association — applied per element. In Symfony 4+: a ~30-line (single) / ~50-line (collection) custom AbstractType wrapping HiddenType with an IdToEntityTransformer built on EntityManagerInterface, registered as a service. This removes two framework-level dependencies and restores testability.

Compatibility. Assume PHP ≤7.1 and Symfony ≤2.8. Treat any claim of PHP 8 or Symfony 5/6 support as unverified — the 2.1.0 notes make no such claim. Do not attempt to satisfy its constraints in a modern composer.json; conflicts will surface as unresolvable graphs rather than clean errors. Verify the 2.1.0 tag's composer.json directly rather than inferring from the release note.

Sequencing.

1. Confirm the requirement is genuinely "entity reference the user cannot choose," not "entity reference the user should not see the list of."
2. Decide single-vs-collection scope up front; 2.1.0 makes collection support available but does not decide whether you need it.
3. Write the transformer + per-element authorization in-house this sprint; the effort is well under a day for the single case and roughly a day for the collection case.
4. If a legacy Symfony app already depends on the bundle, vendor a fork into the monorepo, pin 2.1.0, and wrap it behind an internal type so call sites are insulated from the eventual replacement.
5. Schedule removal against the next form-layer refactor; do not let it become load-bearing.

Operational Impact

Maintenance — you own it on day one, with a marginally better outlook. No releases in eight years prior to 2.1.0, no issue triage cadence established, no patch guarantee. The 2.1.0 merge from an external fork is evidence someone besides the original maintainer touched it; treat that as a one-off contribution, not a succession plan. A fork still means you inherit Symfony deprecation debt with no upstream to rebase onto. Budget the fork as permanently yours or skip it.

Support. Documentation is a README; 2.1.0's new capability arrives with a PR link rather than documented usage, so the collection behavior — payload format, ordering, duplicate handling — must be read out of the source. There is no community to escalate to. Onboarding any new engineer requires them to learn an unfamiliar Symfony Form abstraction to understand behavior that a native Laravel hidden input would make self-evident.

Scaling — new feature amplifies the existing inefficiency. Runtime cost was one entity lookup per submitted hidden field; with one-to-many support it is one lookup per element in each collection, still unmemoized and still unbatched. A form with several hidden entity fields, one of which carries twenty related IDs, produces twenty-plus sequential find()/findBy() calls on submit. Low absolute cost per request, but a measurable, avoidable N+1 that scales linearly with user-controlled payload size — which is also a cheap amplification vector for unauthenticated or low-privilege submissions.

Failure modes.

• Deleted or unauthorized entity: transformer throws TransformationFailedException; whether that becomes a clean validation message or a 500 depends on error bubbling configuration — verify rather than assume. Unchanged.
• New: partial collection failure — one ID in a set is unauthorized or missing; behavior depends on whether the transformer fails whole-form or silently drops the element. A silent drop is worse than an error.
• New: duplicate or unordered collection payload — 2.1.0's expected semantics for repeated IDs are undocumented; assume nothing about ordering or de-duplication.
• Malformed or non-scalar ID: type juggling, typically silent coercion or an unhandled exception. Now applies per element.
• New: delimiter/format mismatch between rendering and hydration — a value containing the delimiter corrupts the collection mapping; test explicitly.
• UUID or composite keys: likely unsupported, failing in ways that look like data problems rather than type problems.
• Tampered ID: resolves to a real, different entity — the security failure mode, and the one most likely to reach production because the happy path never exercises it. With 2.1.0 the same applies to every element of a collection.
• Framework upgrade: hard breakage with no upgrade guide; 2.1.0 does not change that.

Ramp-up. For an experienced Symfony 2 developer, roughly an hour for the single case, roughly half a day to add the collection case including reading the transformer source for format semantics. For a Laravel team, the cost of learning Symfony Form internals plus Doctrine hydration exceeds the cost of writing the equivalent logic directly — which remains the decisive argument against adoption regardless of the package's other merits.