Nova Rating Field Laravel Package

Product Decisions This Supports

• An admin-input affordance, not a product feature. This is a Laravel Nova custom field — a clickable star selector that renders inside a licensed admin panel. It shapes how operators capture subjective scores on records (review ratings, content-quality tiers, vendor scores, priority or impact inputs) stored on Nova resources. It has no bearing on any customer-facing rating model, display, or aggregation, and should never be allowed to influence one.
• A build-vs-buy call on admin CRUD polish. Every request to "add a 1–5 star input to an admin resource" is a low-leverage decision with three options: adopt this package, use a plain Number or Select field backed by integer|between:1,5 validation, or spend roughly half a day building an in-house Nova field (~150–200 LOC). The PM decision is narrow — does a clickable-star affordance justify any third-party dependency in the admin surface?
• A signal on internal-tooling investment. A 41-star, single-purpose field with zero dependents and no release since December 2019 is evidence that the "Nova field marketplace" is a long tail of niche, unmaintained components. It argues against budgeting for a rich third-party admin-component ecosystem and toward a small, owned, vendored set of fields maintained internally.
• A dependency-portfolio risk decision. Adoption means accepting an unmaintained 2019 artifact into the admin surface — almost certainly incompatible with Nova 4/5 (Vue 3 field API, update:value model), requiring a component rewrite rather than a patch. That is a maintenance-budget call and belongs in the same review as any other dependency.
• Scope boundaries for the customer-facing feature. If we ever surface ratings to end users ("rated 4.2/5"), then display, half-stars, weighting, aggregation, decay, and moderation are all owned by our codebase. This package informs only operator input.
• A cheap reference implementation. Even in a "don't adopt" outcome, the repo is a useful design reference for what a minimal Nova field looks like — one PHP Field subclass, one Vue component, Nova::script() / Nova::style() registration — which shortens the in-house estimate and de-risks the build.

When to Consider This Package

Consider it only when all of the following hold:

• You already run Laravel Nova (paid, licensed) with a licensed dev/test app to validate against — it has zero value outside Nova.
• You are on a Nova version this field actually supports (Nova 1.x/2.x era, PHP 7.x). The only release is 2019-12-24, which predates Nova 4 and 5; assume incompatibility until a half-day spike proves otherwise.
• The requirement is a genuinely simple whole-star, integer-or-null rating on one or a handful of resources — not half-stars, not multi-criteria ratings, not custom icon sets at scale.
• You are prepared to vendor the source into your repo and own it indefinitely. MIT makes that trivial; zero dependents and no upstream releases mean no community safety net and no vendor SLA.
• The alternative — a Number field with min:1 max:5, or a Select — is judged a meaningful UX regression for operators. In most admin panels it is not.

Look elsewhere — or build it in-house — when:

• You need a maintained dependency, a security-review trail, or a support commitment. It fails all three.
• You are on Nova 4 or 5, or on Filament / Orchid / custom Livewire instead of Nova. Filament in particular has actively maintained star components; do not port this.
• You need customer-facing input, half-stars, aggregation, analytics, or moderation — the package does none of that.
• Your team convention is "no unmaintained third-party UI in admin." A hand-rolled field is roughly half a day and eliminates the risk.
• No one can commit to owning the code and re-testing it at every Nova/Laravel major upgrade — the recurring cost is upgrade re-validation, not code churn.

Default recommendation: do not adopt as a dependency. Use it as reference source, replicate the behavior in-house, and own the result. If a fork is ever justified (genuine multi-app reuse), vendor the commit, pin it, register it in a "vendored UI" list with a named owner, and maintain a Nova↔Laravel↔PHP↔Vue compatibility matrix.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a free, MIT-licensed UI widget that adds clickable star ratings to our internal admin panel. It is a convenience for staff data entry — it does not touch anything customers see, and it is not a product feature. The catch is that it was last released in December 2019, has no maintainers, and no other projects depend on it. It almost certainly won't work with our current Nova version without a rewrite. My recommendation is to not take the dependency: the same result is about half a day of our own engineering, after which we own it, we can fix it, and we're not carrying an abandoned vendor into every future framework upgrade.

For engineering: Treat the repo as reference source, not a dependency. The pattern is one Field subclass plus one Vue component registered through Nova::script() / Nova::style() — roughly 150–200 LOC. Vendor it into app/Nova/Fields as StarRating, target the current Nova field API (update:value, Nova.booting((app) => app.component(...)), nova.mix.js), and add what the 2019 original lacks: a clear-to-null affordance, aria-label and keyboard handling, an integer cast on the column, server-side between:1,max validation in the FormRequest (not just field rules), and a plain-text or Number display on index to avoid per-row component blowout on large tables. Pair it with an accessor or cached column for any aggregate ("4.2/5") — never try to make the input widget produce a float.

Framing the decision: the question is not "is this widget good?" — it's "do we want an unowned, unmaintained dependency in our admin surface to save half a day?" The answer is no, but the half-day is still worth spending, because operators get the affordance and we get a component we can maintain in an afternoon rather than a migration project.