- What does signifly/nova-progressbar-field do?
- It is a Laravel Nova custom field that renders a numeric resource attribute as a horizontal progress bar inside Nova, so percentages and completion metrics are easier to scan than raw numbers. Typical uses are onboarding completion, storage utilization, SLA burn, and migration progress on internal admin screens. It is a presentation-layer field only: it does not track jobs, run workflows, or compute business logic. Values come from whatever accessor or resolver you already have on the model.
- Which Laravel Nova versions does this progress bar field support?
- The last release was September 2019, which places it in the Nova 1.x/2.x and Vue 2 era. It should be treated as unsupported on Nova 4 and later, where Nova ships Vue 3 and a Vite-based asset pipeline. Before evaluating further, check the package composer.json constraints against your installed laravel/nova version with composer why-not laravel/nova. If you are on a modern Nova release, assume the compiled component will not mount.
- How do I install signifly/nova-progressbar-field?
- Installation is a standard Composer require followed by registering the field in your Nova resource, with optional service-provider and asset publishing steps depending on the version. A working proof of concept is well under a day of work for a Laravel and Nova developer, assuming the Nova generation matches. The real feasibility question is not whether it installs, but whether the install is correct for your Nova version. Confirm the Composer constraints before spending time on configuration.
- Is signifly/nova-progressbar-field still maintained?
- No. The repository is archived, has roughly 5 stars, zero dependents, and no upstream maintainer, with the last release in September 2019. Adopting it means owning an abandoned front-end asset pipeline for the sake of a colored bar. The practical mitigation is to vendor a fork or reimplement the field in-house rather than depend on upstream.
- How do I configure the progress bar field?
- The documented API is the usual fluent field chain, for example ProgressBar::make('Progress')->min(0)->max(100). The blurb describes the bar as customizable, but the exact surface beyond min() and max(), such as color, threshold, or suffix helpers, is not documented in the available material, so read the field class source before relying on it. Whatever you configure, keep the field read-only in forms unless you have verified write behavior yourself.
- Does the field clamp values outside the min and max range?
- Do not assume it does. The typical implementation applies the value as a CSS width percentage with no clamping, so a value of -4 or 150 renders as an overflowing or broken bar, and high-precision floats can look misaligned. Resolvers that average an empty collection can also produce division-by-zero or NaN results. Normalize and clamp values in your accessor or resolver before they reach the field.
- Can I use this progress bar field on Nova index views?
- The field is primarily aimed at forms and detail views, and index support is not documented, so verify it before planning around it. If you do surface resolved values on index views, watch the N+1 exposure created by whatever resolver computes each row. For a large index, a plain Number field with min and max constraints is often the cheaper and safer choice.
- Does signifly/nova-progressbar-field work with Nova 4, Vue 3, and Vite?
- Almost certainly not. The package ships a compiled Vue 2 component built with the older Laravel Mix pipeline, and that bundle will not mount in a Nova 4+ Vue 3 and Vite environment. There is also no documented path for rebuilding the assets against a modern pipeline, which matters if you fork. Treat Nova 4 compatibility as a rewrite, not a configuration change.
- Does the package have tests, and is it safe to use in production?
- There is no test coverage, no security review, and no accessibility review, and the component predates current accessibility expectations. For an internal admin-only indicator the risk is low but real; for customer-facing surfaces it is a poor fit. If you adopt it, keep it scoped to internal Nova resources and pin the exact version you vendored.
- Should I fork this package or write my own Laravel Nova progress bar field?
- Rewriting is usually the better option. The field is roughly 50 lines of PHP plus a small Vue component, which makes a first-party Nova field with your own Nova::script registration a credible alternative to adoption. A fork is the second choice and is only worth it if you can rebuild the compiled assets and take ownership of them internally. Check the license first to confirm it permits private vendoring and forking, and decide up front who owns the code and what triggers deprecation.