Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Nova Percent Field Laravel Package

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.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Build-vs-buy on a single admin field. The real comparison isn't "package vs. nothing" — it's "carry a small vendored field" vs. 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.
  • Scope triage for percentage entry screens. It supports back-office CRUD where a human types a rate by hand: discount rates, VAT/tax rates, commission rates, completion thresholds, scoring weights. It does not calculate totals, enforce business rules, round to policy, format for locale, or feed reporting. If a story says "calculate" or "enforce," this field is not the implementation — it's the input widget in front of it.
  • A storage-contract decision that must be made once, explicitly. Adopting the field forces a choice: whole percent (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.
  • Risk acceptance with an owner. 21 stars, zero dependents, last release 2018-09-26. The PM decision is not "select a vendor" — it's "accept ownership of a small piece of abandoned code." Approve only if the maintenance tax is somebody's explicit job, with a fallback (delete the wrapper, use native Number) written into the ticket.
  • Roadmap scoping guardrail. This can unblock small internal Nova work and be closed the same sprint. It should never anchor a roadmap item, a pricing commitment, or a tax/commission feature promise. Percentages driving billing, payouts, or regulatory numbers need application-level logic and precision handling — the field has no domain awareness whatsoever.
  • Go/no-go screening for use cases. Good fit: internal-only, simple entry, low blast radius, reversible mistakes, named maintainer. Poor fit: pricing engines, multi-currency tax, payouts, regulatory or precision-sensitive finance, public-facing forms, or any requirement for locale-aware decimal input.
  • Deal with known failure modes up front, as acceptance criteria. 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.

When to Consider This Package

Consider it only when all of these hold:

  • You already run Laravel Nova and need a plain percent input in an internal admin panel.
  • Compatibility is verified, not assumed — or you have an owner willing to fork. The 2018 release targets Nova 1/2-era APIs (Vue 2, Laravel Mix, 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.
  • The need is a display/input convention only — not calculation, rounding policy, locale formatting, or compliance logic.
  • Blast radius is contained: internal users, reversible mistakes, and a named maintainer who can patch or replace it.
  • You can pin the dependency, validate in staging, and accept that the next Nova major upgrade probably forces a FormField.vue rewrite.

Look elsewhere when:

  • You're on a modern Nova version and can't confirm compatibility — assume a port, not a drop-in.
  • You need maintained support, security updates, or community adoption. None of those exist here.
  • You need real validation, decimal precision, comma-decimal locale support, or cross-field business rules (parts summing to 100, discount vs. margin).
  • The percentage drives billing, taxes, payouts, or any high-integrity workflow.
  • Native Nova number formatting, a small custom field, or existing application-level validation would be cheaper than carrying an abandoned dependency.

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.

How to Pitch It (Stakeholders)

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.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route
mirvan/ippanel
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource