nsavinov/nova-percent-field
A Laravel Nova field for entering and displaying percentage values. Adds a dedicated percent input with formatting and validation, so percentages store and render cleanly in Nova resources without custom field code.
Number::make('Rate')->step(0.01)->min(0)->max(100)->suffix('%')->rules(...). For greenfield Nova work, native number formatting usually wins on total cost. This package only wins when an existing install already depends on it and the fraction-to-percent display convention is worth keeping.15 = 15%) or fraction (0.15 = 15%). That decision propagates to seeders, factories, API resources, imports, exports, analytics, and finance reporting. Treat it as a product/data decision with a named sign-off (whoever owns finance exports), not something each developer re-decides per resource. Lock it in a wrapper field so it can't drift.Number) written into the ticket.null silently coerced to 0 (turning "no discount set" into "0% discount"); client-side min/max mistaken for validation (API writes and Nova actions bypass it); asymmetric save/display transforms producing "saved 1500%" bugs; step defaulting to 1 and blocking 12.5 with no server-side error. Each of these is a one-line product requirement, not a surprise bug report.Consider it only when all of these hold:
Nova::script() asset registration); modern Vite-built Nova may not mount the component at all. Check the laravel/nova constraint in composer.json before committing to a date.FormField.vue rewrite.Look elsewhere when:
Also confirm before committing: step is set deliberately (0.01, not the default 1); null handling is explicit on both sides of the round trip; every client-side constraint is duplicated in ->rules(); and save/display transforms are exact inverses, tested by round-tripping.
Executive summary: This is a tiny Laravel Nova UI field for typing percentages into internal admin screens. It can save a little build time for teams already standardized on Nova, but it is not strategic and carries lifecycle risk: 21 stars, zero dependents, no release since September 2018. Approve it only as a contained admin convenience with a named owner and a fallback plan — never as a platform dependency, and never as the foundation for pricing, tax, or payout capability.
Engineering summary: Verify Nova/PHP/Laravel compatibility before promising a timeline — the package pins a restrictive laravel/nova constraint that may refuse to resolve on a modern install. Expect a fork or a FormField.vue rewrite rather than a drop-in. If adopted, install behind normal dependency pinning, wrap it in one project-owned field class so the storage convention, rules, step, and formatting live in a single file, and write tests for the fraction-vs-whole-percent round trip, null handling, and server-side validation duplicated from any client-side attributes. Otherwise use native number formatting with a suffix.
Product summary: Use it for internal rate-entry screens where a percentage is just a number someone types in. Don't rely on it for calculations, rounding, locale formatting, or anything customer-facing — those remain product and engineering decisions enforced in application rules and reporting, not in the field. Lock the storage convention with whoever owns finance reporting, budget a short validation spike up front, and expect to own the code if you adopt it.
How can I help you explore Laravel packages today?