Nova Polymorphic Field Laravel Package

Technical Evaluation

Architecture fit. The package sits entirely in the Nova admin presentation layer — it is not a domain, service, or infrastructure dependency. That keeps the architectural blast radius small: adopting or dropping it does not reshape application code, only admin forms. For TPM purposes this is the key point: it's a UI convenience for a back-office capability (attaching morphable records — comments on Posts/Videos, media across entity types, audit entries) that would otherwise be built by hand. A TPM should treat this as an admin-tooling decision within the Nova boundary, not a platform commitment.

Diligence flag — documentation drift. The package description (a morphTo polymorphic selector) and the supporting assessments (a discriminator-driven conditional field container) describe two different behaviors. Both can be true of the same codebase, but the README and the two framings do not reconcile cleanly. Before any spike, a TPM should require the team to read src/ and confirm which capability is actually delivered — the vendor story is the first thing to fail on an unmaintained package.

Integration feasibility. Composer install is the only plausible path, against a 2020-era Laravel/Nova/PHP matrix. No release since 2020-05-04, 66 stars, zero dependents means there is no ecosystem pressure to keep constraints current. Realistic expectation: a non-trivial chance the package will not resolve on a modern Nova (v4/v5) stack and will need a fork. Budget a half-day compatibility spike as a hard go/no-go gate — a failed install is a decision, not a bug to chase.

Technical risk. High. Three compounding factors: (1) abandonment — no upstream fix will arrive; (2) version drift — five years across Nova's custom-field and asset pipeline; (3) weak validation — no downstream projects to surface breakage or compatibility patches. MIT licensing is the one favorable variable: it converts "abandoned dependency" into "vendored source we can own," which is a far more manageable risk profile than a proprietary dead end. The mitigating factor unique to this package is that it is admin-only, behind Nova's auth and policies, so an unmaintained component here has a much lower blast radius than anything customer-facing.

Key questions. Which exact Nova/Laravel/PHP/Node versions are in scope, and does the package resolve there? Which capability do we actually need — morphTo selection or conditional field grouping — and does Nova's native field for the relevant version already cover it? Is the behavior display-only, or does it drive validation/authorization that must be mirrored server-side? Who owns the fork and the upgrade runbook? What is the fallback if the field fails to render? Is the admin UX value worth a permanent line item on every future framework upgrade?

Integration Approach

Stack fit. Laravel + Nova only. PHP backend integration plus compiled Nova/Vue frontend assets. It is not a general form library and has no relevance outside Nova admin panels. A TPM should confirm the target app is actually on Nova before investing further.

Migration path. Native-first: verify Nova's built-in MorphTo field (Nova 4+) or native conditional-field support before touching this package. If the native path falls short, run an isolated-branch spike: fork the repo, reconcile composer.json, confirm asset publishing, and smoke-test one representative resource. Adopt the fork pinned by tag/commit; document the patch set. If native is close enough, use this package only as a UX reference and close it out.

Compatibility. Gate on the exact pinned matrix. Do not use --ignore-platform-reqs as a production workaround — it hides drift rather than resolving it. Expect breakage on Nova 4/5 until proven. Confirm the service provider, field class, Vue components, and published assets all behave under the target environment.

Sequencing. (1) Inventory use cases — is this capability needed in one resource or several? Repetition across resources is the strongest argument for a shared field over hand-rolled code. (2) Confirm no native equivalent. (3) Compatibility spike (half a day). (4) Fork and tag only after the spike passes. (5) Add feature/UI tests and server-side validation mirroring. (6) Pilot on one low-risk resource; roll out resource-by-resource. (7) Keep a documented rollback to native fields.

Operational Impact

Maintenance. High relative to value delivered. Upstream is dead, so the adopting team inherits Composer constraints, JS asset builds, Nova-upgrade patches, and regression testing. The maintenance tax is small in absolute size (the package is ~1–2 dev-days to rebuild) but permanent — it becomes a line item on every Nova/Laravel/PHP upgrade. A TPM should frame this as "fork and vendor," not "add a dependency," and price the recurring cost, not just the adoption cost.

Support. No vendor, no SLA, no active upstream. Support is entirely internal: documented fork location, named owner, upgrade runbook. Low stars and zero dependents mean the community troubleshooting channel is effectively absent. The MIT license permits the fork but confers no ongoing support.

Scaling. Runtime scaling is irrelevant — this is admin UI logic. The scaling concern is organizational: every additional Nova resource using the field widens the regression and upgrade surface. A TPM should cap adoption to a defined set of resources and avoid letting the fork become a transitive dependency of a shared internal package (with zero upstream dependents, the adopter is the only party who will ever notice a break).

Failure modes. Composer resolution failures on modern stacks; broken Vue assets after Nova upgrades; conditional fields rendering stale or blank; validation bypass where UI-only logic is not mirrored server-side; silent UI regressions with no upstream signal; and — the strategic failure — an abandoned dependency quietly blocking a future Nova major upgrade. Mitigations: version pinning, smoke/feature tests, server-side validation in a FormRequest, and a pre-agreed fallback.

Ramp-up. Low for anyone already fluent in Nova custom fields; moderate for teams new to Nova's Vue asset pipeline and field-value store. A TPM should allocate spike time, fork time, and test-writing time up front, and require a named long-term PHP/Nova owner as an adoption precondition. If nobody owns PHP/Nova indefinitely — or the admin is maintained by an agency that won't carry a fork — the correct TPM call is to decline.

TPM recommendation. Conditional adopt / fork. Do not take it as a long-lived Composer dependency. Gate on: Nova version (native first), a passed compatibility spike, admin-only scope, and an internal owner. Revisit at the next Nova major upgrade. The downside is bounded — a couple of dev days and a maintenance line item — which is what makes this a small, reversible decision rather than an architecture commitment.