Rating Field Laravel Package

Product Decisions This Supports

• Scoping admin-side scoring vs. customer-facing ratings. This is a Nova form field — a star input inside the staff-facing admin panel. It supports the question "can moderators tag a record with a 1–5 quality score?" and explicitly does not support "should we build customer reviews, average ratings, or vote history?" Naming that boundary early prevents a cheap admin UX decision from being mistaken for a product capability commitment in a roadmap review.

• Build vs. buy, with the honest third option. The real build cost is roughly half a day to a day: php artisan nova:field scaffolding plus a thin Vue component. That reframes the decision entirely — the comparison point isn't a competitor product. It's (a) a plain Number field with min/max, which costs nothing and carries zero dependency risk, and (b) the default worth choosing: vendor the source into app/Nova/Fields/ and own it. This package is a shortcut and a reference implementation, not a capability purchase.

• Compatibility gating as a forcing function. Nova 4 is Vue 2; Nova 5 is Vue 3. A field last released 2023-04-20 is almost certainly Nova 4. Adopting it forces an answer to "which Nova major are we pinned to, and what's our upgrade posture?" — useful even if we decline the package.

• Roadmap sequencing for internal-ops tooling. Relevant anywhere staff enter structured judgments: QA scorecards, vendor/partner grading, triage prioritization, content-quality scoring, interview feedback. A star widget reduces data-entry friction versus a raw number box, but it's a UX nicety, not a differentiator. Price it as an afternoon, not a sprint.

• Vendor-vs-depend as a standing policy question. Zero stars, zero dependents, single author, no release in two years. The decision this package genuinely enables is "vendor the source into our repo with a named owner" — legitimate and cheap. It is not an "adopt as a maintained dependency" decision, and the PM should say so in exactly those words.

• Rollback story as a deliverable. The fallback is a Number field with min/max and a suffix. Documenting that in the runbook costs nothing and converts a dependency risk into a config flip.

When to Consider This Package

Adopt it (as a vendored copy, not a composer dependency) when all of these hold:

• You are on Nova 4 / Vue 2, confirmed by reading the <script> block of the SFC — not assumed from the version number.
• The need is a single nullable quality score on an internal resource, whole stars only. Half-stars add column-type, cast, and validation drift that must all change in one commit.
• You have a release checklist with a manual smoke test for Nova assets. This field fails quietly: a missing bundle renders a plain number input or nothing, submits fine, and users say nothing. That silent-degradation mode is the entire risk, and the smoke test is the entire mitigation.
• You can commit to pinning the exact version, copying src/ into the repo, attributing the license, and naming an owner.

Look elsewhere — or build in-house — when:

• You're on Nova 5. Porting a Vue 2 field costs about the same as scaffolding a new one, and you'd own the ported result anyway. Build, don't port.
• The requirement is growing into averages, per-user vote history, sorting by rating, or public-facing stars. That's a domain model, not a form input. No field package does that work.
• The form is customer-facing or accessibility-critical. Star widgets are notoriously keyboard- and screen-reader-hostile, and verifying ARIA value and arrow-key behavior is on you.
• You need a maintained dependency with a support path. There isn't one. Don't pretend otherwise in a stakeholder update.

How to Pitch It (Stakeholders)

For executives: This is a small UI component for the internal admin panel — it lets staff pick a 1–5 star score instead of typing a number. Value is modest data-entry friction reduction; it is not a product differentiator and not a user-facing ratings feature. Cost is roughly half a day including integration and a manual QA pass. Because the package itself is a single-author, zero-adoption project with no release since April 2023, we would copy the source into our own codebase and own it rather than take a dependency on it. If you'd rather avoid even that, a plain number input delivers 90% of the value for zero risk — that's a legitimate call and I'd support it.

For engineering: Treat wamesk/rating-field as a reference implementation, not a library. One PHP Field subclass plus one Vue SFC — about 45 minutes of reading. Wrap it in a house App\Nova\Fields\Rating subclass so every call site is Rating::score() and the swap to an in-house build is one file. Settle the storage contract first — that's the only expensive decision. Everything else is a UI swap. Put validation truth in a FormRequest, not in field ->rules(), because imports and API writes bypass the field. Watch three specific traps: half-star values arrive from Vue as strings (validate numeric, not integer, or you reject the feature you configured); 0 and null mean different things and must render differently on the index; and every deploy touching Nova assets ships with the one-page smoke check. Add one line to the Nova upgrade runbook now: re-validate form/detail/index under the new major; fallback is Number with min/max.