Nova Hidden Field Laravel Package

Product Decisions This Supports

Admin-tooling velocity — not product differentiation. This package only touches Laravel Nova resources, i.e. the internal back office. It should be evaluated on delivery speed and maintenance cost, never treated as strategic architecture. No roadmap item changes based on whether it exists; the decision is purely "does this save the team a few days of internal tooling work."

A recurring feature pattern: context injection on create. The canonical shape is stamping a record with a value the operator should not choose — tenant_id, organisation_id, owner_id, parent_id (creating a child from a parent's detail screen), an attribution source, or a workflow status default. Any backlog item phrased "create X from within Y's admin screen" leans on this. Several such items queued is the signal to standardise; a single instance is not.

Build vs. buy is really adopt vs. write ~30 lines. The entire dependency is one PHP field class plus a trivial (or absent) front-end component. We are never locked in, because the escape hatch costs an afternoon. So the PM question is not "is this vendor credible?" but "is a four-year-old snippet cheaper to validate than to rewrite?" For most teams, the honest answer is: spend one hour proving it works, then vendor the class and own it.

Use cases worth standardising across resources: multi-tenant admin panels, audit/ownership stamping on creation, state-machine defaults for new records, and foreign keys set by navigation context rather than by form input.

Documentation drift is itself a finding. The package copy promises declarative conditional visibility and reactive cross-field behaviour; the actual code is a static hidden input with a default value. Plan against the code, not the copy. Nothing richer than "render an invisible input carrying a value" should be roadmapped.

What it explicitly does not unlock: dependent/conditional fields, computed values derived from other fields, per-role form variation, or server-side enforcement. Those are separate decisions with separate estimates — do not let this package's existence create a false "we already have that" assumption in planning.

A risk-register entry, not just a task. The realistic failure mode is silent: the field mounts but never submits, and null foreign keys surface weeks later in production admin data. That argues for a scoping decision — use it only where a missing value degrades gracefully (attribution, UI convenience defaults), and keep invariants (tenancy, ownership, audit trails) in the model layer regardless of whether we adopt this.

When to Consider This Package

Adopt only when all of these hold:

• You already run Laravel Nova and have a repeated need for hidden inputs across several resources — not a one-off.
• You have proven compatibility with your Nova major. This is the gating criterion. The last release was 2020-05-20, predating Nova 4 and Nova 5, and laravel/nova isn't on Packagist, so Composer cannot block an incompatible install. Assume it does not work until a spike shows the component registers and the value actually persists.
• Your team is light on Vue capacity and wants a drop-in rather than authoring a field.
• The blast radius is contained: internal admin only, no customer-facing surface, and no data-integrity invariant that a silent rendering failure could corrupt.
• You accept it as a snippet to vendor, not a dependency to inherit. Zero dependents, no maintenance surface — treat the repo as copy-paste source.

Look elsewhere, or write it in-house, when:

• It's a single use case. One class is cheaper to own than to audit.
• You need maintained code, or supply-chain policy forbids unmaintained dependencies (no patch path, no stated support policy, 33 stars, zero dependents).
• Nova's built-ins already cover you. Check hideWhenCreating() / hideWhenUpdating() / onlyOnDetail() / ->default() / ->withMeta() first — a meaningful share of "hidden field" requests are satisfied by the framework, and duplicating framework behaviour is pure liability.
• The requirement is a server-side default, not a hidden input. Ownership, audit trails, and tenancy belong in fillUsing, a model observer, or a service — with no field at all. Keep invariants out of the browser.
• You need conditional or computed behaviour. The package doesn't do it and should not be extended to do it.

Mitigating factors for the decision memo: MIT licence, no transitive weight, no migrations or config, and a code surface auditable in under an hour. If it fails the spike, fork it rather than reject the pattern.

How to Pitch It (Stakeholders)

For executives. This is a small accelerator for our internal admin panel — a single-purpose helper that pre-fills values an operator shouldn't have to pick, such as the tenant, the owner, or the parent record. It carries no customer-facing risk and no strategic lock-in: the licence is permissive, the code is tiny, and if we need to walk away we can replace it in-house in under a day. The honest caveats are that it hasn't been updated since 2020, nobody else depends on it, and its published description overstates what it does. Recommendation: timebox a one-hour compatibility check against our Nova version; if it clears, use it to save a few days of admin-panel work, and treat the code as something we copied rather than something we depend on.

For engineering. One field class, MIT, zero dependents, last touched 2020. The only real question is Nova-version compatibility — spend an hour proving it renders and submits on our major before it goes near a shared resource, and watch for the silent failure mode where the field never persists (null foreign keys discovered later in production data). Remember a hidden input is client-supplied and trivially editable via devtools: it is a convenience default, never an authorization or integrity control, so the server must still validate and derive anything that matters. Also note ->default() applies only when the field renders and has no existing value — use fillUsing() for anything that must be recomputed on every save, and avoid ->rules('required') because it will fire on actions and non-UI paths where the component never mounted. If it fails the spike, don't argue with it — copy the class into our codebase, own it, and move on. Do not extend it: the moment we need conditional or computed behaviour, we write our own field.