Nova Translation Laravel Package

Technical Evaluation

Architecture fit

• The package is a Laravel/Nova extension: v2.0.0's sole stated change ("Upgrade to nova 4") indicates it plugs into Laravel Nova's tool/card/field/filter surface rather than the core framework.
• Fit is therefore conditional on Nova already being in the stack. Nova is a commercial, license-gated first-party package; adopting this dependency implicitly adopts Nova 4's hosting, licensing, and upgrade cadence.
• If the product does not use Nova, this package has no integration path — it is not a general-purpose Laravel library.

Integration feasibility

• Standard Composer install with Laravel package auto-discovery; expect a service provider plus publishable config/assets (vendor:publish).
• Nova 4 requires a modern Laravel/PHP baseline (Laravel 9+, PHP 8.1+) and replaced the Nova 3 front-end build with Vite. Any package that ships compiled assets must be rebuilt against that toolchain, which is the likely substance behind the one-line note.
• Feasibility is high for a greenfield Nova 4 install; low-to-moderate for an existing Nova 3 install, since the upgrade is gated on a Nova major upgrade first.

Technical risk

• Breaking by definition. v2.0.0 is a major bump whose only described change is a Nova major upgrade. The Composer constraint almost certainly drops nova ~3.0, so v2 cannot coexist with Nova 3. Consumers must move Nova and this package in lockstep.
• Thin release communication. A single-line note for a major version is insufficient evidence of a migration guide, changelog, or deprecation record. This is the principal risk: we cannot confirm whether public APIs, config keys, published assets, or tool/field behaviour changed beyond the framework bump.
• Commercial dependency chain. Risk inherits from Nova licensing and Nova's own release cadence, over which we have no influence.
• Unknown maintenance posture. No repository metadata was supplied (maintainer count, commit recency, test coverage, CI status).
• Silent-regression exposure. Nova 4 front-end changes can break custom fields/tools in ways that only surface at runtime in the admin UI, not in PHP test suites.

Key questions

1. What is the exact Composer constraint on laravel/nova in v2.0.0, and is there a supported v1.x line still receiving fixes for Nova 3?
2. Beyond the framework bump, did any public API, config key, translation key, published asset path, or Vue component contract change?
3. Is there a published upgrade guide, CHANGELOG, or codemod from v1 to v2?
4. What Laravel and PHP versions are supported, and what is the test matrix (Nova versions × Laravel versions × PHP versions)?
5. Who maintains the package, what is the release cadence, and is there a security disclosure process?
6. Does the package ship prebuilt assets, and if so were they rebuilt with Vite for Nova 4?

Integration Approach

Stack fit

• Target baseline: Laravel 9/10, PHP 8.1+, Nova 4.x, Node 16+ for asset publishing if assets are shipped unbuilt.
• Confirm alignment with our pinned Laravel and PHP versions before committing; Nova 4's floor may exceed our current runtime.

Migration path

• On Nova 3 today: stay pinned to the package's v1.x line. Do not attempt a partial upgrade. Plan Nova 3 → Nova 4 as a single, separately scheduled workstream, then move this package to v2.0.0 within that same change.
• On Nova 4 already: adopt v2.0.0 directly; treat as a fresh install and verify published config/assets against defaults.
• Fresh adoption: install v2.0.0 only; no legacy surface to reconcile.
• Treat the package upgrade as a follower dependency in the Nova 4 migration, never as the driver.

Compatibility

• Build an explicit matrix before scheduling: our Laravel version, PHP version, Nova version, package version. The v2.0.0 release note gives no support window, so pin exact versions in composer.json and record the resolved lockfile.
• Verify composer why-not laravel/nova 4.* on a scratch branch to surface conflicts early rather than mid-migration.

Sequencing

1. Confirm Nova 4 is on the roadmap and licensed; without that, this package is blocked and the assessment is moot.
2. Inventory current usage: which Nova resources, fields, tools, cards, and filters come from this package, and who depends on them.
3. Snapshot the Nova 3 admin UI behaviour that must be preserved (screenshots, golden-path test scripts) — Nova 4 will change rendering regardless.
4. Upgrade Nova 3 → 4 on an isolated branch; resolve core Nova breakage first.
5. Add package v2.0.0; re-publish assets; clear caches (config:clear, view:clear, nova:publish as applicable).
6. Regression-test every admin surface that touches the package, plus one negative path (permissions/authorization on the tool or field).
7. Roll out behind a staging environment; keep the Nova 3 branch revertible until sign-off.

Operational Impact

Maintenance

• The package's lifecycle is now welded to Nova's major versions. Expect a forced major upgrade here roughly every time Nova ships one — budget it as recurring, not one-off.
• Pin the version explicitly. A caret constraint across a Nova major boundary is a production incident waiting to happen.
• Track upstream Nova release notes as the leading indicator for this package's health; a package that lags a Nova major by more than a few months is a signal to evaluate alternatives.

Support

• Single-line release notes suggest limited maintainer bandwidth or a solo maintainer. Escalation paths are likely GitHub issues only, with no SLA.
• Mitigation: vendor the package source, or fork and maintain internally, if the admin surface it provides is business-critical. Budget a small ongoing engineering allocation for this.
• Nova support itself comes from Laravel; separate that from package support when triaging.

Scaling

• Admin-panel extensions scale with back-office usage, not end-user traffic — typically low concurrency. Primary scaling concerns are query performance in custom fields/filters and asset payload size, not horizontal scale.
• Audit any package-provided filters or metrics for N+1 queries or unbounded table scans before exposing to operations staff on large datasets.

Failure modes

• Composer resolution failure during a Nova upgrade — the most likely and most disruptive, blocking unrelated work on the same branch.
• Asset/toolchain mismatch after the Vite transition: blank or unstyled admin panels that pass PHP tests and fail in the browser. Highest-severity silent failure.
• Undocumented behavioural drift in fields or tools (validation, formatting, authorization) that passes smoke tests and corrupts data entry in production.
• License lapse on Nova taking the whole admin surface, and this package with it, offline.
• Abandonment — no v3 when Nova 5 arrives, stranding us on a frozen Nova version.

Ramp-up

• Low for a Laravel-fluent engineer: standard package install, service provider, publish-and-configure loop — roughly half a day to first working install on Nova 4.
• Moderate for the Nova 4 migration itself: unfamiliarity with Nova's Vite asset pipeline and the tool/field extension contracts is the real cost, not this package.
• Recommend one engineer own the Nova 4 migration end-to-end and produce an internal runbook (install, publish, cache-clear, regression checklist) so the next forced major upgrade is a repeatable procedure rather than a rediscovery.
• Given the information gap, allocate explicit discovery time before committing to a delivery date — the one-line release note is not sufficient basis for an estimate.