Hidden Entity Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a small form utility. The entire scope of this package is narrow: bind an entity reference into a form as a hidden input and resolve the submitted identifier back to a Doctrine entity. That is roughly 40–100 lines of first-party code in either Symfony or Laravel. The PM decision is whether to carry an external dependency for something an engineer can own in under a day — and the answer here is ownership, which removes a supply-chain line item and gives you control over the security behavior.
• Legacy framework modernization roadmap. The package explicitly targets Symfony 2, which reached end of life in 2018. If it appears in a dependency scan, that is a signal that part of the estate is on an unsupported framework. Treat it as evidence for scoping a migration track (Symfony 3.4+/5+/6+/7 — or a Laravel consolidation, if that is the actual strategic stack), not as a reason to invest in the bundle.
• Security posture for hidden-ID fields. A hidden field carrying an entity identifier is fully user-controlled; hiding the input provides zero protection. Every adoption or retention of this pattern obliges a product-level policy: the server must resolve the entity and authorize ownership/tenant scope on every submission. This is a decision about a mandatory authorization contract, not about which package to install.
• Wizard, multi-step, and edit-form UX patterns. The legitimate product need behind this package is avoiding a giant entity-selection dropdown on add-comment, add-line-item, and edit screens — a performance and UX motive, not a security one. The decision is which implementation: hidden ID plus server-side validation, signed/hashed identifiers, or purely server-side session carry-over. Each has different tamper-resistance and different implementation cost.
• Dependency intake policy. 0 stars, 0 dependents, 0 score, single maintainer, no visible release cadence, no CVE monitoring. That is not an argument about this package alone — it is a data point for setting a minimum bar a dependency must clear before entering code that handles forms and entity resolution.
• Laravel stack implication. Framed as a Laravel/PHP candidate, the package fails at the first gate: it is a Symfony bundle with no Laravel Form component, no form factory, and no data-transformer pipeline to plug into. The decision it actually supports is a scoping one — "reimplement the pattern internally as a thin Laravel helper," which is roadmap effort, not procurement evaluation.

When to Consider This Package

• Only in a narrow legacy-maintenance scenario: you have an actively running Symfony 2.x application, you are not migrating it this quarter, the bundle is already in composer.json, and you need a drop-in form type rather than a bespoke one.
• Preconditions if retained: MIT license compatibility (fine), a pinned version or vendored fork, a named internal owner, and an explicit removal date logged as tech debt. Upstream support is effectively absent, so nothing can be assumed about future fixes.
• Look elsewhere — or build — when:
  • Your stack is Laravel. Do not evaluate this as a Laravel candidate. The Symfony Form component and Doctrine ORM are not first-class there; there is no host container or transformer pipeline. Independently, the bundle targets the pre-3.0 Symfony Form API (setDefaultOptions, replaced by configureOptions) and PHP 5.x-era constraints, so it would fatal against any supported modern version anyway. Composer resolution fails; only reimplementation is realistic.
  • You are on Symfony 3.4 or later. The equivalent is a small custom AbstractType with a hidden field and a PRE_SUBMIT handler or data transformer. A few hours of work removes the dependency entirely.
  • The hidden value influences authorization, pricing, ownership, or tenant scope. Prefer signed identifiers or server-side session carry-over, kept in first-party code where the authorization check is non-optional.
  • You need maintained releases, security advisories, or community escalation. None are available.
  • You need polymorphic or multi-entity hidden resolution. Not a supported use case; build the specific shape you need.
• As a design reference only: for a Laravel team, the repository is worth ten minutes of reading — the semantics (hidden scalar in, authorized model out) map cleanly onto a Blade hidden input, Rule::exists(...)->where(...) scoped to tenant, findOrFail, and a Policy check. Extract the pattern, discard the implementation.

How to Pitch It (Stakeholders)

Executives: This is a single-purpose utility bundle for a framework that has been end-of-life since 2018, with no community, no dependents, no release cadence, and no security monitoring. It adds supply-chain and audit surface for functionality we can own in under a day of engineering time, and it does not come with the authorization safeguards our forms actually need. Recommendation: do not adopt it as a strategic dependency. If any usage exists on a legacy Symfony 2 system, pin or vendor it short-term with a named owner and a removal date, and retire it alongside the broader framework-upgrade track. For our Laravel work it is simply out of scope — the cost is a one-day internal build, not a migration project.

Engineering: The bundle does one thing: render an entity reference as a hidden form field instead of a full entity select, then transform the submitted scalar back into a managed Doctrine entity. That is a small custom form type plus a data transformer. Writing it ourselves is faster than wrapping this, lets us bake in the defenses the bundle lacks, and avoids an unmaintained fork we alone would have to support. The pattern, not the code, is the deliverable — and it ports cleanly: hidden input in Blade, Rule::exists() or a custom rule for existence and tenant scoping, findOrFail for resolution, a Policy for ownership. Enforce three things as part of the contract: hidden does not mean trusted; authorization runs on every submit, not just on render; and resolved models are never passed straight into fill()/update() without an explicit allow-list. Add tampering tests for the obvious cases — valid ID, foreign-tenant ID, deleted ID, non-numeric input, soft-deleted record — and put a review checklist item against any future hidden-ID field that lacks an authorization check. Action: confirm no existing internal equivalent, place the helper in application code or a shared support package, document the pattern in team conventions, and drop the composer requirement.