Currency Context Filament Laravel Package

Technical Evaluation

Architecture fit

• This is a presentation adapter, not a domain library. It bridges a module-currency-context domain module to Filament UI (panel resources, widgets, possibly a topbar currency switcher). Value is only realized if we already run Filament admin panels and have a genuine multi-currency display requirement.
• The modular decomposition (module-currency-context domain + -filament adapter) is sound in principle — it keeps currency resolution logic out of Livewire components and lets the same context serve API/console surfaces. That is the correct seam for a monolith using nwidart/laravel-modules or a similar convention.
• Coupling risk is architectural as well as version-based: the adapter is a leaf node that presumes a specific domain contract (resolver interface, session/user persistence model, rounding policy). If the parent module's contract is unstable or undocumented, the adapter is a thin shell over an unknown core.

Integration feasibility

• Two-package install: we must adopt the parent currency-context module and this adapter, roughly doubling surface area and diligence versus what the repo name implies.
• Filament is a fast-moving dependency with breaking changes across majors. With zero dependents and zero stars there is no signal that this adapter tracks Filament releases. We would be the first production consumer — effectively an unpaid beta tester.
• Practical feasibility is high in effort terms (likely a few hundred LOC, standard service-provider registration) but low in confidence terms.

Technical risk

• License is the hard blocker. NOASSERTION is not a permissive license; it means the scanner could not identify one. Until counsel clears it, this cannot ship in a commercial product. Treat as non-adoptable by default.
• Provenance anomaly: a release dated 2026-10-26 is in the future. Either the registry metadata is unreliable or the release process is automated/backfilled. Both interpretations reduce trust in the artifact we would be pinning.
• Bus factor 1, zero adoption, zero dependents. No issue history, no external bug reports, no community patches.
• Global-state hazards: currency context is inherently request/session-scoped. Under Octane or in queued jobs (mail, invoices, PDF generation) a leaked or default context silently produces wrong-currency output — a class of bug that is financially material and hard to detect in QA.
• Composite score of 19.8 with opportunity 45 suggests the problem is underserved, not that this package solves it well. That reading matters: it argues for building rather than adopting.

Key questions

1. What license governs this repo and the parent module-currency-context? Can we get written clarification from the maintainer?
2. Which Filament major(s) and Laravel/PHP versions are supported, and what is the declared composer constraint range?
3. How is currency context persisted and resolved — session, user preference, tenant, or per-panel default? Is there a documented resolver interface we can implement ourselves?
4. Is context explicitly reset/bound for queued jobs and Octane workers, or is it ambient global state?
5. Does the parent module own rounding/formatting policy, or does the adapter? Where does the money-precision contract live?
6. Is there any test suite, and does it run against a matrix of Filament versions?

Integration Approach

Stack fit

• Qualifies only if the target application is Laravel + Filament with a real multi-currency presentation need (regional price display, admin currency switching, per-tenant base currency). If Filament is absent, or if we only need a single display currency, this is a no-op.
• Better fit for teams already standardized on the Liberu module family; otherwise it introduces a second, unfamiliar modular convention alongside our own.

Migration path

• Preferred: spike, then vendor. Run the pair in a throwaway Filament panel for one iteration to extract the domain contract, then either (a) fork both packages into an internal namespace under a clarified license, or (b) reimplement the adapter against our own context service — the adapter layer is small enough that reimplementation is likely cheaper than dependency management.
• Avoid adopting as an unmodified upstream dependency: no maintainer responsiveness signal plus a fast-moving host framework equals predictable breakage with no upstream fix path.
• Budget: 1 spike iteration (3–5 days) for evaluation plus contract extraction; 1 sprint to harden or reimplement with tests.

Compatibility

• Pin exact versions in composer.json; do not float constraints on a package with no dependents. Lock the parent module and the adapter together — they are effectively a single unit.
• Verify PHP 8.2+/8.3 support and confirm the Filament major against our panel version before any code is written.
• Confirm no transitive dependency conflicts with our existing admin stack (Filament plugins, Livewire, spatie/laravel-package-tools).

Sequencing

1. Legal/license clearance on both packages — gate everything behind this.
2. Version-matrix verification (Filament × Laravel × PHP) in a sandbox.
3. Contract extraction: document the context resolver interface and persistence semantics.
4. Build-vs-fork decision.
5. Implement with an explicit context-reset contract for jobs/Octane and a test matrix covering currency switches, rounding, and concurrent users.
6. Ship behind a feature flag; validate against a reconciliation check (displayed currency vs. persisted currency) before general availability.

Operational Impact

Maintenance

• We would assume de facto ownership. The adapter's small surface is deceptive: it sits on the Filament upgrade treadmill, which requires attention every major release, plus every minor that touches panel rendering or Livewire lifecycle.
• Two packages to track, one of which (the domain module) carries the substantive logic we have no visibility into. Ongoing cost is low-to-moderate but concentrated at upgrade windows.

Support

• No vendor support path, no community, no dependents to observe for regressions. Internal Slack-channel support only, which means our platform team absorbs all escalations.
• Mitigation: fork under our namespace so we can patch without waiting on an absent maintainer.

Scaling

• Presentation-layer cost is negligible at typical admin traffic. The real scaling concern is resolution frequency: if currency context is resolved per request or per Livewire render without caching, it becomes a hidden N+1 against user/tenant settings. Cache per session with explicit invalidation.
• Correctness scales worse than performance: as tenants, currencies, and locales multiply, ambient context becomes an increasingly likely source of mispriced output.

Failure modes

• Silent wrong-currency output — the highest-severity mode. Context fails to bind in a queued job or Octane worker and falls back to a default; invoices, exports, or syncs are produced in the wrong currency with no error raised.
• Rounding/precision drift — ambiguity over whether the adapter or domain module owns formatting, producing display values that disagree with persisted minor units.
• Filament upgrade breakage — panel renders but the switcher is inert; failure is cosmetic-first, which delays detection.
• Abandonware drift — parent module evolves or stalls independently; the adapter silently desynchronizes from the contract.
• License exposure — discovered late in a procurement or open-source review; forces emergency removal.

Ramp-up

• Technical ramp is genuinely low: a Laravel developer understands the adapter in under a day.
• Due-diligence ramp is the real cost — license clarification, provenance verification, and contract documentation will consume more effort than the integration itself, with no guaranteed answer at the end.
• Recommendation to stakeholders: do not adopt as a dependency at this time. Use it as a reference implementation to inform an in-house adapter (est. 1 sprint) or revisit if the maintainer publishes an explicit OSI license, a supported version matrix, and at least one production dependent.