Nova Progressbar Field Laravel Package

Technical Evaluation

Architecture fit: This is a Laravel Nova custom field — a presentation-layer plugin that renders a numeric resource attribute as a horizontal bar in Nova forms, detail views, and potentially index views. It fits only stacks already running Nova and needing a small internal admin-UI enhancement: onboarding completion, storage utilization, SLA burn, migration progress, or similar percentage-based metrics. It is not a progress engine, job-status tracker, workflow primitive, or business-logic component. Architecturally it is a leaf dependency: a PHP field class plus a compiled Vue 2 component. The blast radius of adoption is small, but so is the leverage. A TPM should treat this as a reference implementation or a small internal utility, not a strategic dependency or roadmap differentiator.

Integration feasibility: Mechanically simple. Composer install, optional service-provider/asset registration, then ProgressBar::make(...)->min(0)->max(100). A Laravel/Nova engineer can produce a working proof of concept in under a day, assuming Nova generation matches. The feasibility question is therefore not "can we install it" but "is the install correct for our Nova version." Last release was September 2019, which places it in the Nova 1.x/2.x, Vue 2, Laravel Mix era. On Nova 4+ (Vue 3 / Vite) the compiled component will not mount. Check composer why-not laravel/nova and the package's own composer.json constraints before any deeper evaluation.

Technical risk: High relative to delivered value. The repository is archived, has 5 stars, zero dependents, and no upstream maintainer. Concrete risks include Nova major-version incompatibility; stale compiled JS assets that cannot be rebuilt against a modern pipeline; no test coverage; undocumented edge behavior (values are typically applied as width: {value}% with no clamping, so -4, 150, or a high-precision float renders as an overflowing or broken bar); division-by-zero and NaN from resolvers that average an empty collection; and no security or accessibility review. The value is a colored bar. The cost is owning an abandoned front-end asset pipeline. The mitigation is cheap and obvious: the field is roughly 50 lines of PHP plus a small Vue component, so a first-party reimplementation is a credible alternative to adoption, and a fork is a credible alternative to dependency.

Key questions:

• Which Nova version is supported by the package's Composer constraints, and which Nova version are we actually on?
• Are compiled assets shipped and publishable, and can they be rebuilt if we fork?
• Is the field read-only, and does it expose color/threshold/suffix helpers beyond min()/max()? What is the actual API surface versus the README?
• What license applies, and does it permit private vendoring/forking?
• Do the resolvers we intend to use run on index views, and if so, what is the N+1 exposure?
• Who owns this code internally after adoption, and under what trigger do we deprecate it?
• Is the UI gain worth any permanent ownership cost, or is a Number field with ->min(0)->max(100) sufficient?

Integration Approach

Stack fit: Conditional. Adopt only where the product already runs Laravel Nova and the need is an internal, admin-facing progress indicator. Do not introduce Nova, or a Nova upgrade, to obtain this package. Do not use it in customer-facing surfaces where accessibility and design-system consistency matter, since the component predates current a11y expectations and carries no maintenance commitment. A TPM should scope this as admin UX polish, not product differentiation, and should resist any attempt to put it on a customer-facing roadmap.

Migration path: Assume the upstream package will not be depended on directly. Two viable paths, in order of preference. First, reimplement as a small first-party Nova field — copy the PHP field class, write or adapt a minimal Vue component, register your own Nova::script, and own it outright; this is the lowest long-term cost and gives control over clamping, thresholds, and asset build. Second, fork into an internal namespace, pin via path repository or private VCS, and record provenance with the original license header preserved and a replace entry or path reference in composer.json so future maintainers understand the abandoned upstream. A third, lighter option exists if the PHP class is adequate but the component is not: keep the package's field class and point it at your own component with ->component('my-progress-bar'), avoiding a PHP fork. Whichever path is chosen, the package should never appear in production composer.json as an unmodified archived dependency.

Compatibility: Validate Composer constraints against installed Nova, Laravel, PHP, and the front-end build chain before committing. Assume 2019-era targeting and treat Nova 3/4/5 support as unproven until demonstrated. Test in a non-production Nova instance. If the Vue component is forked and rebuilt, confirm the current asset pipeline (Vite for Nova 4+) and hard-refresh after builds — Nova caches hashed asset names, so stale manifests are a frequent false negative.

Sequencing:

1. Confirm Nova version and the specific field requirements (read-only, threshold coloring, detail vs. index placement).
2. Inspect package source and license; read src/ProgressBar.php and the Vue component to establish the real API and clamping behavior.
3. Run a timeboxed proof of concept in a non-production Nova instance against a computed value, including null and out-of-range cases.
4. Decide fork vs. reimplement. Default to reimplement unless the PoC is clean and the fork is trivially small.
5. Establish internal ownership: owner, README, upgrade checklist, and a note that upstream is archived.
6. Add the field to Nova upgrade regression checks so version bumps do not silently blank the UI.
7. Only then extend to additional metrics — one field instance per metric, not a multiplexed component.

Operational Impact

Maintenance: Upstream maintenance is zero — the repository is archived, so there will be no dependency updates, asset rebuilds, Nova compatibility fixes, or documentation from the author. Every one of those becomes internal work. In practice the maintenance burden is low per incident but permanent: each Nova major upgrade requires revalidating the field and its compiled assets. Budget it as a small utility with an indefinite tail, not a one-time integration.

Support: Community support is negligible at 5 stars and 0 dependents; there is no meaningful issue-tracker backstop. Internal support must cover installation, configuration, troubleshooting, and the "why is the bar blank" class of ticket — which is almost always a Nova version mismatch or a bad resolved value rather than a Vue fault. Keep the code surface minimal, document the field's props and clamping rules, and note in the runbook that the /nova-api/{resource}/{id} JSON response is the first diagnostic step.

Scaling: Runtime scaling is a non-issue; this is a presentational admin field and one bar costs nothing. The real scaling constraint is organizational and query-shaped. Progress values are usually derived, so resolveUsing closures that count relations will produce N+1 queries on index views unless the relation is eager-loaded in indexQuery(). Prefer model accessors over per-row closures where a metric is reused. As the number of bars grows, so does the number of resolvers that must be reviewed for denominator guards and clamping.

Failure modes: Nova major-version incompatibility (blank field, unknown custom element, or asset compile error); missing or stale compiled assets after a fork or rebuild; broken field registration in the service provider; rendering errors specific to index versus detail views and narrow viewports; out-of-range values producing overflowing bars because the component does not clamp; NaN or exceptions from unguarded denominators over empty collections; null values rendering as empty where a dash or hidden field was intended; and silent display drift when a resolver's semantics change but the bar keeps rendering a plausible-looking number. displayUsing() will not affect the bar — it formats text, not width — which is a predictable source of "the formatting doesn't work" confusion. Security exposure is low given the admin-only surface, but the code should still be reviewed before it enters a production bundle.

Ramp-up: Developer ramp-up is low for anyone fluent in Laravel and Nova; the API is a make() plus min()/max() and the component is small enough to read in one sitting. The hidden overhead is ownership, not learning: asset pipeline, version compatibility, resolver hygiene, and upgrade regression testing. A TPM should timebox evaluation to roughly one engineer-day, expect the recommendation to land on "reimplement in-house," and treat the package primarily as a working reference for that build rather than a dependency to onboard.