Nova Header Field Laravel Package

Technical Evaluation

Architecture fit

• The package is a single Nova custom field (Header extends Laravel\Nova\Fields\Field) plus a Vue component. This is the canonical Nova extension pattern, so conceptually it slots into any fields() method with no service provider wiring beyond package discovery.
• Fit is strong in principle — a header is a presentation-only concern and adding it as a field avoids invasive resource restructuring (extra panels, raw HTML in help() text, or custom layouts).
• However, the value proposition is thin: modern Nova ships a first-party Heading field and Panel grouping. A TPM should treat this as a "build vs. buy vs. already-have" decision, not an obvious dependency.

Integration feasibility

• Composer install is trivial; no transitive dependencies ("lightweight and dependency-free") keeps the lockfile clean and the security surface negligible.
• Real integration cost lives in the Nova asset pipeline: this is a 2018-era field, targeting Nova 2.x's Vue 2 component registration and nova.mix/npm run dev conventions. Nova 3/4/5 changed asset compilation, field component resolution, and in some versions the Vue major. Expect the published JS to be the failure point, not the PHP class.
• Because it is a display-only field with no persistence (->onlyOnForms()/->exceptOnForms() semantics are inherited), the blast radius of a broken render is cosmetic — a section label disappears; no data loss, no migration, no schema coupling.

Technical risk

• Abandonment risk: high. Last release 2018-10-15 — no commits across multiple Nova majors. 9 stars, 0 dependents means effectively no community backstop and no one else discovering the breakages for you.
• Compatibility risk: high. No stated Nova/PHP/Laravel version constraints in the brief; almost certainly pinned to a Nova line you are not on.
• Correctness risk: low. It renders a string. There is no business logic to get wrong.
• Security/supply-chain risk: low — MIT, no dependencies, tiny code surface. Still, an unmaintained package in a Composer manifest is a long-term audit finding.
• Opportunity cost is the real risk: a 30-line in-house field (or the built-in Heading) achieves the same outcome with an owner, tests, and an upgrade path.

Key questions for the team

1. Which Nova major version are we on, and does that version already provide Heading/Panel that satisfies the UX goal? If yes, this package is redundant — stop here.
2. If we adopt it, do we accept forking it into our own namespace (App\Nova\Fields\Header) rather than requiring the upstream package?
3. Does the field need to work in detail views, inline relations, and HasMany/BelongsToMany subforms? Nova renders those through different component contexts, and a 2018 component may not survive them.
4. Is the styling acceptable under our Nova theme, or does it need CSS overrides that we would then own forever?
5. What is our policy on abandoned Composer dependencies, and does an unmaintained UI-only field warrant an exception?

Integration Approach

Stack fit

• Laravel + Nova, Composer-managed, no runtime services, no config, no migrations. It is a pure presentation dependency and therefore the lowest-possible coupling to our application domain — it can be added and removed without touching models, policies, or resources.
• The one genuine coupling is to Nova's front-end build, which is where version drift will bite.

Migration path

• Preferred: don't install it. Validate whether Nova's built-in Heading field or Panel covers the requirement. If it does, adopt that and record the decision — zero maintenance burden, no fork to own.
• Fallback: vendor/fork it. Copy the PHP class and Vue component into our own Nova field namespace, register it locally, and rebuild assets with our project's Nova toolchain. This converts an unmaintained dependency into ~50 lines of code we control, which for a package this small is cheaper than the governance overhead of an exception.
• Avoid: composer require as-is. Acceptable only as a spike to evaluate rendering, not as a production dependency for a multi-year application.

Compatibility

• Treat Nova version as the gating constraint. Build a small compatibility check before any adoption: install into a scratch Nova project at our exact version, confirm the field resolves (Nova::script/component registration), renders in create, update, and detail contexts, and survives nova:publish/production asset build (npm run prod).
• Confirm PHP constraint compatibility (a 2018 package may declare php: ^7.1 and block a PHP 8.2+ upgrade path or force --ignore-platform-reqs).
• Verify no conflict with the built-in Heading field namespace/component name — component collisions in Nova are silent and confusing.

Sequencing

1. Requirements check — document the actual UX problem (long form, poor grouping) and confirm the built-in Heading/Panel cannot solve it. Likely this ends the evaluation.
2. Spike (½ day) — install upstream in a throwaway branch, render in one resource's form and detail view.
3. Decide — adopt built-in, adopt fork, or reject.
4. If fork — add to app/Nova/Fields, add a PHPUnit/Nova test asserting field component and meta, wire into the Nova asset build in CI.
5. Rollout — pilot on one high-traffic resource (e.g., the longest form), gather admin feedback, then apply pattern across resources.
6. Document — record in an ADR why the package was forked/rejected so the next engineer doesn't re-evaluate it.

Operational Impact

Maintenance

• Upstream maintenance is effectively zero. Every Nova upgrade — especially major versions — becomes our problem, and Nova majors ship roughly annually. Budget a recurring line item for "re-verify custom Nova fields," or eliminate it by owning the code.
• A fork reduces risk to near zero: the component is small, self-contained, and can be covered by a single regression test.
• License (MIT) is permissive; no legal friction for forking, provided attribution is retained.

Support

• No vendor, no active maintainer, 9 stars, 0 dependents — no community to escalate to and no Stack Overflow corpus. Internal ownership is mandatory regardless of adoption path.
• Failure is discoverable by users (missing headings) rather than by monitoring; expect feedback via admins, not alerts. Add a Nova smoke test if heading-driven form usability is load-bearing.

Scaling

• Performance impact is negligible: one field instance per heading, no queries, no serialization cost, no added payload weight beyond a small Vue component.
• The scaling concern is form scale, not user scale — the package exists to manage forms with dozens of fields. If forms are that large, the deeper fix is resource decomposition (tabs/panels/relations), which Nova supports natively and which this package does not address.

Failure modes

• Silent non-render after Nova upgrade — component name or asset pipeline changes; heading vanishes without an error. Highest-probability failure.
• Vue runtime error breaking the whole form — a stale component compiled against the wrong Vue major can throw during render and take the surrounding field stack with it. This is the one genuinely disruptive failure mode; validate in the spike.
• CSS/theme drift — heading styles hardcoded for 2018 Nova markup will look wrong under current themes; cosmetic but erodes trust in the admin UI.
• Dependency freeze — the PHP version constraint blocking a platform upgrade is a classic abandoned-package failure and far more expensive than the field itself.
• Component name collision with Nova's native Heading, causing one to shadow the other unpredictably.

Ramp-up

• Engineering ramp-up is minimal: any Laravel developer understands a Nova field in under an hour, and the source is small enough to read end-to-end.
• TPM ramp-up is the real cost: someone must own the decision and the upgrade verification. Assign that owner explicitly.
• Recommendation: reject as a production dependency; satisfy the requirement with Nova's native Heading/Panel, or, if the styling truly differs, fork the ~50 lines into the application and own it. The package is functionally sound and architecturally elegant, but at seven years stale with no adopters, the maintenance cost it transfers to us exceeds the effort of reimplementing it.