Filament Ethiopic Calendar Laravel Package

Technical Evaluation

Verdict: conditional spike, not a default adopt. This is a narrow presentation-layer plugin (Ethiopic/Ge'ez calendar rendering for Filament table columns) with a small but real value proposition for Ethiopian-market admin panels. Its technical footprint is tiny; its vendor footprint is the problem.

Architecture fit

• Purely additive formatting concern. No schema changes, no persistence, no service-provider hooks into request lifecycle beyond Filament panel registration. Blast radius if removed: one column class swap.
• Correct architectural stance is canonical storage in UTC/Gregorian, conversion only at render time. If we adopt this package we must explicitly forbid it leaking into models, casts, or form input — that would create a second source of truth for dates and is the single biggest design risk.
• Filament's column API is the integration surface, and it is the most volatile part of the framework between majors. We are coupling to a fast-moving internal API of a fast-moving framework via a 2-star dependency.

Integration feasibility

• Composer require + register in PanelProvider — a half-day including tests. The hard part is not installation, it is verification.
• Open question whether the package ships a Filament Plugin object or just a column/macro; the description ("Add Ethiopic datetime to your filament tables") implies table columns only, which means no form/DatePicker support — users will still enter Gregorian dates. Confirm before promising anything to stakeholders.

Technical risk

Key questions to answer before approval

1. Exact Filament major + PHP + Laravel constraint range in composer.json. Does a ^4.0 path exist?
2. Which conversion library is used — andegna/calender, a vendored implementation, or hand-rolled arithmetic? Is it tested against known fixtures?
3. Is there a test suite, and does it cover leap years (2015/2016 EC), Pagume 6, and year boundaries?
4. Is conversion applied before or after timezone/->timezone() resolution on the column?
5. Does it handle null, CarbonImmutable, string dates, and custom casts without throwing?
6. Are Amharic/Ge'ez month and day names configurable or hardcoded?
7. Who is the maintainer, and is there any stated support expectation?

Integration Approach

Stack fit — Laravel 10/11/12 + Filament 3/4 + PHP 8.1+, MIT-licensed, no infrastructure requirements. Fits cleanly for any team already running Filament; there is no realistic scenario where adopting this changes our architecture.

Migration path — There is nothing to migrate. Adopt and revert are both single-commit operations if we isolate the dependency behind an internal wrapper. The real migration question is the inverse: if we later add Ethiopic date input or Ethiopic-native reporting, this package will not carry us there, and we will need a broader calendar-conversion layer. Treat this as a display-only stopgap, not the foundation of an Ethiopian localization strategy.

Compatibility

• Pin the Filament major and record it in an ADR. Run composer why-not against our actual lockfile rather than trusting the README's constraints.
• If constraints are too tight (e.g., Filament 3 only while we're on 4), fork under our org namespace rather than downgrading the framework. MIT makes this trivial and the code volume is small.

Sequencing

1. Spike (0.5 day): install in a scratch branch; render an Ethiopic column against a fixture table.
2. Correctness harness (1 day): assert conversion output against a hand-verified fixture set — Meskerem 1 for three consecutive Gregorian years, a Pagume 6 leap day, and a 23:30 UTC timestamp. This step is non-negotiable and is where most of the effort belongs.
3. Adapter layer (0.5 day): wrap the column in an internal App\Filament\Columns\EthiopicDateColumn so the vendor class never appears in resource files. This is the mitigation for both the bus-factor risk and Filament API drift.
4. Pilot (1 table): one low-stakes, read-only listing (audit log or similar) in production.
5. Rollout: only after two weeks of clean pilot, and only to display contexts. Block any PR that uses it outside table columns.

Total realistic cost: 2–3 engineer-days including the verification harness — roughly 3–4× the naive install estimate, and justified entirely by the correctness risk.

Operational Impact

Maintenance — The dominant cost. Plan for de facto fork ownership within 12 months: expect to carry the package, bump Filament constraints ourselves, and fix conversion bugs directly. With 2 stars and 0 dependents, upstream responsiveness is a hope, not a plan. Assign a named owner. Budget a few hours per Filament major upgrade.

Support — No SLA, GitHub issues only, single maintainer. We need an internal runbook covering "how to verify a reported wrong date" — otherwise the first support ticket about a date discrepancy becomes an unbounded investigation. Given the domain (Ethiopian users, likely finance/HR/government-adjacent data), date correctness tickets will be treated as high severity by stakeholders regardless of actual impact.

Scaling — Effectively non-existent as a concern. Calendar conversion is integer arithmetic; cost is O(rows rendered) and negligible against Filament's existing hydration and query cost. No caching layer, no queue, no external calls. The only scaling-adjacent note: if the package pulls a heavier transitive dependency than expected, it adds autoload weight to every request — check composer show --tree once.

Failure modes

1. Silent wrong date (highest impact). No exception, no log line, just a plausible-but-wrong day. Mitigation: the fixture harness in CI, not manual review.
2. Filament upgrade breaks the column class — loud and immediate (fatal on table render), therefore low risk. Fails fast, easy to detect.
3. Null/invalid datetime throws — medium; test against nullable columns before pilot.
4. Timezone day-boundary skew — medium; a record stored at 21:00 UTC renders as the previous Ethiopian day. Must be an explicit, documented decision, not emergent behavior.
5. Dependency disappearance/yank — low; MIT + small code = vendor into the repo if the package becomes load-bearing.

Ramp-up — Low for engineers. Any Filament-competent developer is productive in under an hour. The genuine ramp-up cost is domain knowledge: the team must learn enough Ethiopian calendar mechanics to review the fixture set credibly. Without at least one person who can independently validate a conversion, we cannot distinguish "the package is right" from "the package is consistently wrong." Staff or contract that expertise before the pilot, not after.

Recommendation to the steering group: approve the spike and the correctness harness; do not approve broad rollout until (a) Filament constraint compatibility is confirmed against our lockfile, (b) fixtures pass, and (c) the adapter wrapper is in place. The package itself is fine engineering in a small package — the assessment's low composite and opportunity scores are an accurate read on ecosystem durability, and our mitigation should be ownership transfer (fork + wrap), not avoidance.