Nova Translatable Laravel Package

Technical Evaluation

Architecture fit. This is a single-responsibility presentation-layer adapter: it renders JSON-backed translation columns managed by spatie/laravel-translatable as a locale-tabbed Nova field. No schema changes, no service-provider surgery, no domain-layer footprint, no exposure to customer-facing request paths. If the stack already runs Nova plus spatie/laravel-translatable, the conceptual fit is close to ideal — a UI convenience confined to the admin panel. If either half of that pair is absent, the package has no job to do and the evaluation ends. That two-part precondition is the first gate a TPM should apply, because it collapses most of the decision space in one question.

Integration feasibility. Mechanically trivial (Composer require + register the field on a Nova resource). Practically constrained: last release 2021-08-29 and archived, placing it squarely in the Nova 3.x era. Nova 4 (2022) reworked the field lifecycle and moved the asset pipeline from Mix to Vite; Nova 5 adds further drift. A 2021-era field class plus compiled Vue assets is unlikely to run unmodified on a current Nova major, and 2021-era PHP produces deprecation noise on 8.2/8.3. The TPM framing is therefore patch-and-own, not install — and the package's own composer.json pins are the first thing to diff against the target matrix.

Technical risk.

• Version skew (high likelihood): archived code against a commercial framework with an annual major cadence and a vendor-driven upgrade clock. Our paid Nova renewal cadence becomes coupled to a dead dependency.
• Data integrity (high severity): the field's fillUsing/resolveUsing logic is the only guard between an editor and silently clobbering sibling-locale translations. A stale implementation against a changed Nova field contract is a plausible path to silent content loss — the one failure mode here that destroys business value rather than merely annoying editors.
• Supply chain (moderate): archived repositories get no CVE triage and no security response process.
• Bus factor zero: 81 stars, 0 dependents, single historical maintainer. No community to absorb fixes, no downstream canary to learn breakage from.

The mitigating factor is blast radius: Nova is internal back-office tooling. Failure degrades editorial workflow; it does not take down the product. The opportunity: 10.86 signal should be read as "the gap is real and unserved," not "this artifact is the vehicle." It argues for solving the problem, not for adopting this repo.

Key questions.

1. Which Nova major are we on, and what is the upgrade/renewal cadence? Nova 3.x makes this viable as-is; 4.x+ means fork-or-skip.
2. Has spatie/nova-translatable — the first-party equivalent — been evaluated? A maintained first-party field is almost certainly the correct answer, and this check costs hours, not days.
3. Do requirements diverge from stock (custom locale sets, fallback chains, permission-gated locales)? Divergence is the only real justification for forking rather than buying/reusing.
4. What is the build-vs-fork delta? The surface is small — plausibly 1–2 engineer-days in-house, ~300 lines — which reframes the entire decision from "adopt vs. build" to "build with a head start vs. build from scratch."
5. Is multilingual admin editing on the critical path for a launch or a content SLA, or is it a quality-of-life improvement?
6. Who is the named internal owner if we adopt? No owner, no adoption.

Integration Approach

Stack fit. Laravel + Nova + spatie/laravel-translatable + this field is a coherent chain with one structural caveat: Nova is a licensed commercial product on a vendor upgrade clock, and this field sits directly on top of it, unmaintained. That is the headline constraint — not the install step. Treat the field as an in-tree component of our admin tooling, budgeted and reviewed like our own code.

Migration path. Do not adopt as a normal transitive dependency. Sequence the decision as a tree:

1. First: evaluate spatie/nova-translatable. If it covers requirements, this package is out of scope and the assessment closes — this is the expected outcome and should be timeboxed to a few hours.
2. If requirements diverge: vendor via a path/VCS repository under an org-owned namespace, pin to a commit, treat the source in-tree. Do not consume from Packagist, and do not let a composer require slip into a branch as a "quick win."
3. If the fork needs more than a small compatibility patch: build in-house. Fork cost is not the patch — it is permanent ownership of a release pipeline, CI, tagging, and credentials for ~300 lines of code, which frequently exceeds the code's own value.

Compatibility. Establish an explicit matrix before committing: Nova 4.x and 5.x × Laravel 10/11 × PHP 8.2/8.3. Verify specifically (a) field resolution and hydration contract, (b) Vue component compatibility with the current Nova asset pipeline (Mix vs. Vite), (c) locale/fallback configuration matches what the app actually uses, and (d) write behavior is proven by test, not by inspection. Any unverified cell in that matrix is an unbudgeted day.

Sequencing.

• Week 0: source review (small, readable codebase) and upstream-alternative check — hours, not days.
• Week 1: decision gate — adopt first-party / vendor-fork / build. Record the decision and its rationale. This is the cheap off-ramp; take it before any engineering spend.
• Week 2: sandbox validation on the target Nova major with a representative translatable model; write a round-trip test asserting that a locale write does not overwrite siblings.
• Week 3+: pilot on one resource type, run in parallel with the existing editorial workflow, then extend resource by resource.
• Close-out: record the ownership decision in the risk register with a named owner and an annual review date tied to the Nova upgrade cycle and license renewal.

Operational Impact

Maintenance. Upstream maintenance is zero — the defining operational fact. Ownership transfers to us on day one: compatibility patches, asset rebuilds on Nova majors, PHP-version hygiene. Budget ~1–2 engineer-days per year steady state, spiking to roughly a week around a Nova major. A fork adds CI, tagging, and a private-registry credential for a very small payload — often more overhead than the code itself. Put the steady-state number in the plan explicitly; unowned dependencies do not have zero cost, they have unbudgeted cost.

Support. No maintainer, no issue triage, no security response. With 81 stars and 0 dependents there is no community to lean on and no downstream signal to borrow confidence from. Every escalation terminates in-house, which means the admin panel acquires an unowned component with no vendor and no on-call path. Log it as "vendored, internally owned" with a named owner and a re-evaluation trigger (Nova major upgrade, PHP/Laravel upgrade, or the addition of a third locale). If compliance or security review requires maintained dependencies with an SLA, this is a hard fail and the conversation ends.

Scaling. Not a throughput concern — the field never touches production request handling. Scaling is editorial: one locale tab per locale per field degrades admin responsiveness on resources with many locales and many fields. Minor, but measure it if locales exceed ~8 or the editorial team grows. The documented sweet spot is 2–4 locales, internal editors, no per-locale approval chains; if requirements grow past simple per-record locale editing, stop extending this and scope a proper editorial workflow instead.

Failure modes.

• Silent translation overwrite — highest severity; the only mode that can destroy business content. Mitigate with a round-trip test and a soft launch on one resource before any wider rollout.
• Field fails to render after a Nova upgrade — high likelihood, low severity; editors lose the UI, not the data.
• Vue asset mismatch / build failure — moderate; blocks admin deploys only.
• PHP deprecation and Composer resolution conflicts — low severity, recurring noise that erodes trust in the dependency.
• Bus factor — no second party can fix anything; a scheduling risk rather than an incident.

All of these are contained to the Nova admin panel. That containment is the strongest argument that this is a tolerable, bounded risk — and simultaneously why it does not merit sustained engineering attention.

Ramp-up. Low. The codebase is readable by a mid-level Laravel developer in under an hour. The real prerequisite is Nova field-lifecycle knowledge — resolution, hydration, dependency container, asset tooling — which is where the learning cost sits and which has limited reuse elsewhere in the codebase. Plan the ramp-up around that, not around the package's own code.

TPM verdict. Do not adopt as a dependency. Leverage it as a reference implementation and fork candidate: use it to validate that the problem is cheap to solve, to shortcut UI design decisions (locale tabs, fallback display, dirty state), and to anchor a small, timeboxed decision gate against spatie/nova-translatable. The ask to stakeholders is deliberately small — one to two engineer-days to vendor and own, versus a multi-week build from scratch or a recurring TMS contract for an internal-only need — with the honest caveat that the package is archived, unmaintained, and pre-dates several Nova majors. If the first-party equivalent fits, take it and close this out. If requirements diverge, fork and own it with a named owner and an annual review tied to the Nova renewal clock. Do not let this package anchor broader localization, workflow, or CMS strategy conversations — it is a CRUD-panel field, not a translation management system.