Filament Calculator Action Laravel Package

Technical Evaluation

Architecture fit

• The package is a UI-layer artifact: a Filament Action that opens a calculator and writes a result into form/table state. It does not touch Eloquent models, migrations, service providers of consequence, or persistence. That is the right shape for a low-commitment dependency — the blast radius is a single interactive control.
• "Zero Livewire round-trips" means the arithmetic runs in Alpine.js in the browser. Architecturally clean for UX latency, but it reclassifies the computed number as untrusted client input. Any value that flows into pricing, tax, totals, or margin must be recomputed or validated server-side. If the team treats the calculator as the system of record for a number, this package becomes a business-logic-in-the-browser problem, not a UI convenience.
• Fit is conditional on being on Filament v3/v4 already. This is not a package that justifies adopting Filament.

Integration feasibility

• Low ceremony: composer require, then either a panel plugin registration or direct use of the action in a resource schema. Surface area is small enough to read end-to-end before adopting — a TPM should require exactly that.
• The stated v3 and v4 support is the primary thing to verify, not trust. Filament v4 split Actions into a separate filament/actions package and renamed several schema-builder APIs. A single codebase serving both major versions is plausible but must be confirmed against the specific pinned versions in our composer.json, not against the README.

Technical risk

• Supply chain signal is weak: 14 stars, 0 dependents, single maintainer. Zero dependents means no external hardening — we would be among the first production consumers, absorbing discovery cost.
• Bus factor of one, MIT license (no warranty, no SLA). Acceptable only with a fork-and-own contingency.
• Floating-point arithmetic in JavaScript for money is a known hazard. Rounding mismatches between what the user sees in the calculator and what the server later computes are the most likely source of a quiet, hard-to-triage defect.

Key questions

1. Does it demonstrably work on our pinned Filament version, in both form-schema and table-action contexts?
2. What is the state-sync contract — does the result commit to the Livewire component via wire:model, or only mutate client state until blur/submit?
3. Does it respect action authorization (->visible(), ->authorized()), or does it bypass policy checks?
4. Where is the rounding mode configured, and can it be aligned to the server-side money library?
5. Does it ship tests and CI? What is the maintainer's stated support window across Filament majors?
6. Can the calculator's expression set be constrained (no free-form input), or does it accept arbitrary expressions?

Integration Approach

Stack fit

• Laravel + Filament v3/v4, Composer, Alpine.js (already bundled by Filament — no new frontend toolchain). No Node build step, no asset publishing requirement assumed; verify.
• Fits admin/back-office surfaces: quote builders, order line editors, discount and margin tools, invoice adjustments. Does not fit customer-facing or high-assurance financial workflows in its current form.

Migration path

• Effectively zero-migration: no tables, no columns, no data backfill. Add, evaluate, and remove without cleanup — which is precisely why a timeboxed spike is cheap and defensible.
• Reversibility is the strongest argument for evaluating it. The cost of a wrong decision is a composer remove and a rewritten action.

Compatibility

• Pin filament/filament and confirm the filament/actions split for v4 before anything else.
• Check PHP version floor against our runtime, and Livewire major alignment.
• Confirm CSP posture: Alpine-based actions can conflict with a strict script-src policy. Not a blocker, but it is the kind of thing that surfaces late in a release cycle.

Sequencing

1. Timeboxed spike (1–2 days) in a sandbox panel, pinned to production Filament version.
2. Instrument one real use case end-to-end — a quote line total is the best test because it forces the client/server rounding question.
3. Decide build vs. buy: a comparable Alpine-powered Filament action is on the order of 100–200 lines. If the package saves less than the cost of owning a fork, write it internally.
4. If adopted: fork into an internal namespace, add a test for the rounding contract, and treat upstream as a source of ideas rather than a dependency.
5. Roll out behind an existing feature flag to one admin surface, measure, then widen.

Operational Impact

Maintenance

• Runtime maintenance burden is near zero: no services, no cron, no migrations.
• The real cost is version-coupling to Filament. Every Filament major will require us to validate or patch this package. With one maintainer and no dependents, that work lands on us by default. Budget for it explicitly or fork up front.

Support

• Community-only: GitHub issues, no vendor, no SLA, MIT warranty disclaimer. Escalation path is "we read the source" — feasible here because the source is small, but that must be a stated team capability, not an assumption.
• Add a named internal owner. Un-owned UI dependencies are how broken admin buttons survive for quarters.

Scaling

• Net positive on infrastructure: moving arithmetic to the browser removes Livewire round-trips, which reduces PHP worker occupancy and websocket/polling chatter on calculator-heavy screens. Effect is small but directionally correct and free.
• No horizontal-scaling concerns. No shared state. No cache or queue involvement.

Failure modes

• Cosmetic failure (most likely): action fails to render or throws in the browser after a Filament upgrade. A dead button, not an outage. Detectable in a smoke test.
• Silent numerical drift (most dangerous): client and server disagree on rounding; totals are subtly wrong and only surface in reconciliation or audit. This is the failure mode that justifies server-side recomputation regardless of whether we adopt the package.
• Authorization bypass: if the action ignores Filament's visibility rules, a user could compute values they should not be able to enter. Verify against policies.
• CSP/asset regression: Alpine directives blocked by a tightened security header, degrading the action to a no-op with no server-side error.

Ramp-up

• For a Filament-fluent engineer: under an hour to wire, an afternoon to evaluate properly. For a team without Filament experience: the action itself is trivial, but the surrounding evaluation requires understanding Filament's action lifecycle and state binding — the dependency is not the learning curve.
• Documentation burden on us: low, but non-zero. Internal guidance should exist on when to use a calculator action versus plain numeric fields, and on the server-side validation rule that must accompany it.

TPM recommendation

Score (0.16) and adoption signals (14 stars, 0 dependents) place this in "evaluate, do not standardize" territory. Approve a short spike against one concrete admin workflow. Default to an internal fork or a hand-written Alpine action unless the spike shows the rounding and state-sync contracts are already sound. The decision should hinge on build-vs-own cost, not on feature novelty — server-side recomputation and rounding discipline are required in either path.