Filament Rating Field Laravel Package

Technical Evaluation

Architecture fit. Unchanged by v0.7.0. yepsua/filament-rating-field remains a narrow, single-purpose Filament form component — a star-rating field type contributed to the Filament schema builder. It does not touch the domain layer, the persistence layer, routing, auth, or the queue. It renders a Livewire-bound form control and stores whatever scalar the developer binds to it. If our admin/back-office surface is already Filament (TALL stack: Laravel + Livewire + Alpine + Tailwind), the fit is essentially native — it is a Field subclass that composes into ->schema([...]) alongside TextInput, Select, and friends. If our surface is not Filament, this package has zero applicability and should be rejected immediately regardless of score.

Integration feasibility. High, and cheap to prove. The integration surface is three lines: a composer require, optionally a plugin registration in the PanelProvider, and a field declaration in the target form schema. Because the blast radius is a single form component, we can validate it end-to-end in an afternoon against a real form and a real Eloquent model. The MIT license removes legal friction. The main feasibility question is not "can we wire it up" but "does it render correctly and persist predictably under our Filament version."

What v0.7.0 changes. One thing, and it is small: PR #25 (new contributor @atmonshi) removes the illuminate/contracts dependency so the package no longer constrains the Laravel version. Net effect on our evaluation:

• Positive: it directly resolves the Laravel-side half of our version-coupling concern. Previously a hard illuminate/contracts constraint could produce a Composer conflict or force a Laravel pin we didn't want; now the package composes with whatever Laravel we run. It also confirms the maintainer merges outside PRs — a modest bus-factor and responsiveness signal that partially answers our earlier "is the maintainer responsive?" question.
• Negative (small but real): the package now declares no upper bound on Laravel. "Supports any Laravel version" is a claim, not a guarantee — there are still zero dependents, so nothing validates that claim but us. Composer will no longer warn us when the package drifts out of a supported Laravel range; the guardrail is gone and our own CI becomes the only detector.
• Neutral: no functional, UI, asset, or Filament-constraint changes are described. Behavior should be identical to v0.6.0. The widget still appears to be integer-input-first; half-stars, read-only display, and custom color theming remain unresolved, so our feature-gap question is unanswered by this release.

Technical risk. Still concentrated in version coupling and bus-factor, with the coupling risk now asymmetric:

• Filament version pinning — still the largest risk, unchanged. Filament's form/field APIs have moved materially across v3 → v4. A rating field is a thin wrapper over Filament\Forms\Components\Field, so it inherits every breaking change in that base class and in Livewire's binding contract. v0.7.0 says nothing about Filament constraints; this is invisible from the star count and is now the dominant unmitigated coupling.
• Laravel version coupling — materially reduced. Was a Composer-visible constraint, now unbounded. Lower friction to install, marginally higher risk of silent drift.
• Zero dependents. No downstream projects publicly validate this package. We would be the first meaningful production consumer, which means we absorb the cost of discovering integration edges (asset registration, dark-mode theming, validation message plumbing) ourselves. v0.7.0 does not change this — one merged PR is a good sign, not a test suite.
• 47 stars, single-vendor provenance (yepsua). Still hobby-to-semi-maintained. Acceptable for a 200-line form widget; disqualifying for infrastructure.
• Scope is genuinely small, exit cost is near zero. The compensating factor remains decisive: worst case we fork it, vendor it, or reimplement in a day with Alpine. v0.7.0 being a one-line composer.json change reinforces how small the maintainable surface is.
• Cosmetic signals. The "Ranting field" typo in the description is still there. A dependency-removal PR merged as a minor version bump with no changelog detail beyond the PR title continues the loose release-hygiene pattern — not dangerous here, but a reason to read diffs rather than trust release notes.

Key questions to resolve before adoption (revised):

1. Which Filament major version(s) does composer.json constrain, and does that match our pinned Filament version exactly? (Now the primary question — v0.7.0 addressed Laravel but not Filament.)
2. Post-v0.7.0, what does the require block actually contain? If Laravel is now entirely unconstrained, we must own the compatibility matrix ourselves.
3. Is the field purely presentational, or does it ship validation rules, a cast, and a migration helper? (Determines whether we also own schema decisions.)
4. Does it publish assets (CSS/Alpine) or rely entirely on Filament's existing Tailwind build? Asset publishing is a deployment-time failure mode.
5. Is the maintainer sustaining the responsiveness shown in PR #25 — i.e., is there a tagged release cadence, and are issues answered?
6. Does it support half-star / fractional ratings and read-only display, or only integer input? v0.7.0 did not close this gap; feature gaps still determine whether we fork on day one.
7. What is the storage contract — integer column, decimal, or JSON — and does it match our existing ratings data, if any?

Integration Approach

Stack fit. Adopt only if the target surface is Filament on Laravel 10/11 with PHP 8.1+ and Livewire 3. v0.7.0 widens the theoretical Laravel range but we should treat the validated range as whatever we test, not whatever composer.json permits. The field remains a presentation-layer convenience, not a data-model decision: we specify the column type and validation ourselves and let the widget bind to it. Do not let a third-party widget dictate schema.

Migration path. Greenfield-friendly, brownfield-cautious, and the v0.7.0 upgrade itself is a no-op for us:

• If we have no existing rating UI, this is a pure additive install with no migration of existing data.
• If we already render ratings via a custom Blade partial, a Select, or a manual Alpine component, the migration is per-form and reversible — swap the field, keep the column. No data migration required.
• If we are mid-upgrade between Filament majors, sequence this after the Filament upgrade lands. Never introduce a new field component during a framework major bump; it conflates two failure domains.
• If we already piloted v0.6.0, no re-pilot is strictly required for v0.7.0 — but do re-run the persistence test after the bump, because the guardrail removal means Composer will not tell us if something upstream shifted.

Compatibility. Pinning is now mandatory, not advisory. Add the package with an exact constraint ("yepsua/filament-rating-field": "0.7.*") rather than a caret range, and record in our dependency notes both the Filament version and the Laravel version we validated against. With illuminate/contracts removed, there is no resolver-level signal at all — neither community dependents nor a Laravel ceiling — so we are the entire compatibility test. Review the v0.6.0 → v0.7.0 diff before upgrading: it should be a single composer.json line, and confirming that is a two-minute check that keeps the "we read diffs" discipline honest.

Sequencing.

1. Spike (0.5 day): install v0.7.0 on a branch, add the field to one low-traffic admin form, verify render, binding, validation, persistence, dark mode, and mobile.
2. Fork decision gate: if the spike reveals missing features (half-stars, read-only, custom colors) or the Filament constraint is wrong, fork into an internal namespace or reimplement as a custom Filament field — this is the cheap path and should be considered a first-class option, not a fallback. v0.7.0 did not change the feature surface, so a v0.6.0 fork decision stands unchanged.
3. Pilot (1 form): ship to a single internal admin screen for one sprint with no external users.
4. Rollout: promote to all rating forms only after the pilot survives a Filament point release without breakage — that is the real compatibility test, and it is now the only one.
5. Contingency: keep the vendored/forked variant behind the same field API so a swap is a one-line change.

Operational Impact

Maintenance. Low ongoing cost, non-trivial ownership cost — and v0.7.0 slightly improves the first while slightly raising the second. The package itself will require little attention, and the removal of the illuminate/contracts constraint means fewer Composer conflicts to chase on Laravel upgrades. But because the package now claims unbounded Laravel support, someone must own the compatibility watch on two axes: re-validating this field on every Filament minor/major bump, and spot-checking it on every Laravel minor. Budget a recurring line item: roughly one hour per Filament release plus a few minutes per Laravel release to smoke-test, and the fork exercise if it breaks. The new-contributor signal from PR #25 modestly reduces — but does not eliminate — the risk of the maintainer going quiet.

Support. No SLA, no vendor relationship, community-only. Our support model must be "internal owner or nobody." Escalation path is: upstream issue → fork. PR #25 is weak evidence that upstream issues get attention; it is not a support channel. Document this in the dependency register so on-call doesn't waste time waiting on a maintainer.

Scaling. Effectively a non-issue. The field is client-side rendering plus one Livewire round-trip per interaction — no different from any other form control. Two cautions: (a) Livewire round-trips on hover/click can be chatty if the field is bound with live(); prefer deferred binding unless the rating drives reactive UI; (b) if ratings are aggregated for reporting, the widget is irrelevant — the index and query plan on the ratings column are our problem and must be designed independently. Do not mistake "small widget" for "small data model."

Failure modes.

• Silent breakage on Filament upgrade — field renders but binding or validation stops firing. Mitigation: a Pest/Dusk test asserting the field persists a value, run in CI against our pinned Filament.
• Silent Laravel drift — newly emphasized by v0.7.0. With no illuminate/contracts constraint, an unrelated Laravel upgrade can move the package outside anything the maintainer tested, and Composer will stay silent. Mitigation: the same persistence test in CI, plus an explicit note in the upgrade runbook that this dependency has no upper bound.
• Asset/theme regression — stars render unstyled after a Tailwind purge or version bump. Mitigation: visual smoke check in the pilot, and confirm whether assets are published or inherited.
• Abandonment — repo goes stale; we are frozen at our pinned version. Mitigation: pre-negotiated fork path; keep the field behind our own thin wrapper so replacement is mechanical.
• Data-shape mismatch — developer binds a decimal column to an integer-only widget and silently truncates. Mitigation: explicit validation rule and a cast test at the model layer.
• Supply-chain — low-traffic package, single maintainer, now accepting external PRs to the dependency manifest. Mitigation: pin to a tagged release, review every diff (v0.7.0's is one line — cheap to verify), and avoid dev-main. The new contributor is a positive signal but also a reminder that manifest changes arrive from outside the original author.

Ramp-up. Near-zero for any developer already fluent in Filament — the field is declarative and self-documenting. Expect ~30 minutes for a Filament-competent engineer, and treat it as a non-topic for anyone else (non-Filament engineers should not be touching this form layer at all). No re-training implied by v0.7.0; behavior is unchanged.

TPM verdict. v0.7.0 is a low-risk, mildly favorable release: it removes the Laravel constraint that was one of our two stated coupling concerns, and it demonstrates the maintainer will merge outside contributions. It does not touch the dominant risk (Filament version coupling), does not add features (half-stars, read-only), and does not change the zero-dependents reality — it trades a Composer-visible guardrail for an unbounded support claim, which raises the value of our own CI and pinning discipline. Recommendation stands: pilot-approve with an explicit fork budget and a named internal owner, upgrade to 0.7.* after a two-minute diff review and a re-run of the persistence test. Adopt for internal admin surfaces where a star rating is a nice-to-have; do not adopt for customer-facing or revenue-critical UI without first forking it into our namespace, because the combination of zero dependents, 47 stars, no Laravel ceiling, and Filament's volatile field API means we — not the maintainer — will be absorbing every future break.