Nova Progress Field Laravel Package

Technical Evaluation

Architecture fit

The package is a Laravel Nova custom field: a PHP field class extending Laravel\Nova\Fields\Field paired with a compiled Vue component registered through Nova's asset pipeline. It is a presentation-layer artifact, not a domain or infrastructure dependency. It does not touch models, migrations, queues, or persistence, and it introduces no runtime coupling beyond the Nova field registry.

That narrow surface area is the package's only genuine architectural strength. It is a leaf node in the dependency graph — safe to isolate, safe to remove, and incapable of cascading into application logic. If the team already runs Nova, the conceptual fit is clean: a progress bar is a first-class Nova use case (task completion, quota consumption, upload state, budget burn-down).

The fit degrades sharply on everything else:

• Nova version coupling is the dominant constraint. Nova 3 targets Vue 2; Nova 4 and 5 target Vue 3 with a reworked asset/build toolchain. A field last released in August 2022 was almost certainly authored against Nova 3 or early Nova 4. On Nova 5 the component may fail to compile, fail to register, or render silently blank.
• Nova is a paid, closed-source product. Compatibility cannot be validated against public source, and Nova's own upgrade cadence forces field rewrites. Any custom field is a recurring tax on every Nova major upgrade.
• No abstraction boundary. The package offers no service provider hooks, config, or extension points worth preserving. There is nothing to integrate with — only something to copy.

Integration feasibility

Mechanically trivial. composer require masoudi/nova-progress-field, then reference the field in a resource's fields() method. No configuration, no migrations, no published assets beyond Nova's standard nova:publish. A single developer can wire it up in under an hour.

The blocker is not effort, it is provenance. The repository is archived, carries 1 star, 0 dependents, and its last release is 2022-08-26. Archival is an explicit maintainer statement that the package will not receive fixes — including fixes for Nova 4/5 compatibility, PHP 8.2/8.3 deprecations, or Vue 3 build breakage. Combined with a composite score of 0.0025, the package should be treated as reference source code, not a dependency.

Technical risk

• Abandonment risk: realized, not latent. Archived status means no security patches, no compatibility updates, no issue triage.
• Supply-chain risk: low but non-zero. A Composer dependency from an unmaintained, single-maintainer, low-visibility repo is a standing invitation to a compromised or hijacked namespace. Zero dependents means nobody else is watching.
• Functional risk: moderate. Progress bar rendering depends on a value the field receives. If the value is computed in PHP (percentage, ratio), the field is cosmetic and low blast radius. If it assumes a specific data shape (array with value/max, or a 0–100 integer), malformed input likely yields a broken bar or a thrown exception rather than graceful degradation.
• Front-end risk: high on Nova 4/5. Vue 2 components do not load in Vue 3 Nova without a rewrite. Expect the field to be non-functional on current Nova, which is the most probable reason it was archived.
• Reputational/compliance risk: low but real. Shipping an archived, zero-adoption package into a production admin panel is a finding in any dependency review.

Key questions

1. Which Nova major version is in production, and does the field's Vue component target Vue 2 or Vue 3?
2. Is the progress value computed server-side by our code, or does the field impose a data contract on the model?
3. Does the field need to be editable (input) or is read-only display sufficient? Read-only collapses the requirement to ~40 lines of Vue.
4. What is the real cost of reimplementation versus the cost of adopting and later replacing an archived dependency?
5. Are there licensing constraints on copying the source into our codebase?

Integration Approach

Stack fit

Appropriate only for teams already on Laravel Nova with a Nova 3-era stack. On Nova 4 or 5, assume the package will not work out of the box and budget for a rewrite. If the team is not on Nova, this package is irrelevant — a plain Blade component or a Tailwind progress bar covers the same need with zero dependency.

Migration path

Do not install as a Composer dependency. Instead:

1. Vendor the source. Copy the PHP field class and Vue component into the application (e.g. app/Nova/Fields/ProgressBar.php and resources/js/nova/components/ProgressBar.vue). This converts an abandoned third-party dependency into first-party code under our control — eliminating supply-chain, archival, and abandonment risk in one step.
2. Re-target the component to the installed Nova/Vue version, updating the build config and component registration to match Nova's current custom-field scaffolding (php artisan nova:field).
3. Harden the value contract. Normalize input in the PHP field (resolve/displayUsing) into a bounded 0–100 integer, clamp out-of-range values, and define behavior for null. Emit a neutral/empty state rather than throwing.
4. Attribute the original in a header comment per the repository's license.

This preserves the 100% of the package's value (a small render component) while discarding 100% of its risk.

Compatibility

Verify explicitly before any work: Nova version, PHP version, Vue version, Node/build toolchain, and whether Nova's asset compilation is used or overridden. The PHP side is near-certainly fine on modern PHP after a deprecation pass; the Vue side is the actual work.

Sequencing

1. Confirm Nova/PHP/Vue versions and read the package source (~1 hour).
2. Decide: vendor-and-adapt versus rebuild from scratch. Given the size, rebuilding against nova:field scaffolding is often faster than adapting unfamiliar archived code.
3. Implement and normalize the data contract.
4. Test on staging across index, detail, and inline-relation contexts.
5. Document the field in the internal Nova component library so the next team does not rediscover the package.

Operational Impact

Maintenance

Ownership transfers entirely to the adopting team. As a Composer dependency: indefinite, unbounded maintenance debt with no upstream. As vendored source: a small, self-owned component with a maintenance cost measured in hours per Nova major upgrade — acceptable and plannable. The vendored path is the only defensible operating model.

Support

None available. Archived repository, no maintainer response, no issue tracker activity, no community of adopters (0 dependents). Internal escalation path is "read the code" — which is viable precisely because the codebase is tiny. This must be stated explicitly in the adoption record so no one assumes upstream support exists.

Scaling

Operationally negligible. The field renders per-row in Nova index views; cost is bounded by Nova's pagination. No queries, no I/O, no caching concerns. At large result sets the constraint is Nova's own table rendering, not this component. There is no scaling dimension on which this package becomes a bottleneck.

Failure modes

• Silent blank field after Nova/PHP upgrade — component fails to compile or register; no error surfaced to the user. Most likely failure, and the reason upgrade testing must include a visual check of every custom field.
• Build pipeline breakage from Vue 2 → 3 migration, blocking the entire Nova asset build, not just this field. This is the highest-severity failure mode and argues strongly for vendoring.
• Malformed value producing an out-of-range bar or an unhandled exception on null. Mitigated by input normalization at the PHP layer.
• CSS collisions with Nova's stylesheet or other custom fields, causing layout drift in table rows.
• Namespace hijack if installed as a Composer dependency from an unmaintained repo. Eliminated by vendoring.

Ramp-up

Near-zero for any developer comfortable with Laravel and Nova. The PHP field is a standard Nova field class; the Vue component is a small presentational component. A mid-level Laravel developer can read, understand, and modify the entire codebase in under two hours. The real ramp-up cost is not the code — it is Nova-specific knowledge (field registration, asset compilation, resolve/displayUsing semantics), which the team needs regardless of whether this package is used.

TPM recommendation: Adopt the pattern, not the dependency. Reimplement or vendor the field under first-party ownership, document it in the internal Nova component library, and record the decision to avoid archived packages in the admin panel as a standing dependency policy.