Filament Ummulqura Date Picker Laravel Package

Technical Evaluation

Architecture fit

• asimnet/filament-ummulqura-date-picker is a Filament form-field plugin that adds an Umm al-Qura (Hijri) date picker — a narrow, presentation-layer concern. It integrates via a Filament service provider and spatie/laravel-package-tools, which is the conventional, low-friction shape for a Filament plugin. No framework-level coupling beyond Filament itself.
• v1.2.2 is a packaging-only change: it declares https://repo.schemava.dev/r/public (a self-hosted Packistry registry) as a composer-type repository so that the backend dependency asimnet/ummulqura-calendar: ^1.1 resolves. No PHP code, no public API, no schema, no config surface changed. Verified resolution to ummulqura-calendar 1.1.0; 13/13 tests pass.
• Functional footprint is therefore unchanged from v1.2.1. The architecture-fit question is not about the date picker — it is about whether we accept a third-party package registry into our dependency graph.

Integration feasibility

• The change is intended to make installation work out of the box, but Composer does not read repositories from a dependency's composer.json — only from the root project's composer.json. A repository declaration shipped inside the package therefore has no effect for downstream consumers; it only affects the package's own development checkout, which is the environment in which the "verified" claim was produced.
• Practical consequence: unless asimnet/ummulqura-calendar is also published on Packagist, composer require asimnet/filament-ummulqura-date-picker will fail for us until we manually add the repository entry to our root manifest. If it is on Packagist, the new repository declaration is inert for us and the release is a no-op in practice. Both branches need to be confirmed before adoption — this is the single most important open item.
• If we do add the repository, configuration is trivial (one repositories block, no credentials apparent from the /r/public path), but it becomes a permanent, project-wide resolution source, not a per-package one.

Technical risk

• Resolution-path dependency (high). A composer-type repository is canonical: every composer update consults repo.schemava.dev for all packages, falling through to Packagist only on a miss. This adds latency, an external availability dependency, and discloses our dependency-graph package names to a third-party registry operator.
• Reproducibility (high). composer.lock will record dist URLs pointing at repo.schemava.dev. composer install in CI then depends on that host being reachable and serving the same artifacts indefinitely. If the registry is retired, renamed, or the package is unpublished, clean builds become unreproducible with no Packagist fallback.
• Supply-chain trust (medium-high). We would be trusting an additional, non-Packagist host controlled by the package author for the provenance of a runtime dependency. No information is given on who operates schemava.dev, its retention, or its access controls.
• Naming ambiguity (medium). "Private Composer repository" versus a path of /r/public is contradictory. If anonymous read is enabled, CI needs no secrets (good) but the artifact is effectively public and unauthenticated; if it later requires auth, every build pipeline must hold credentials.
• Shadowing (low-medium). A multi-tenant registry serving /public could, in principle, serve package names that also exist on Packagist. Canonical repos win those lookups silently.
• Test confidence (low-medium). 13 tests is a thin suite and there is no indication of a PHP/Laravel/Filament version matrix. Adequate for a packaging-only release; weak as evidence of general reliability.

Key questions

1. Is asimnet/ummulqura-calendar published on Packagist, or is repo.schemava.dev the only source? This determines whether v1.2.2 fixes anything for us.
2. Who operates repo.schemava.dev, and is anonymous read guaranteed to remain available? Is there an SLA, uptime history, or deprecation policy?
3. Are the dist artifacts immutable and retained indefinitely, or can 1.1.0 be replaced/removed?
4. What is the license of ummulqura-calendar, and is it redistributable through a private registry?
5. Does the package support the Filament major version we run, and is there a stated support window?
6. Is the maintainer a single individual, and is there a succession/continuity plan?
7. Why was the dependency not published to Packagist in the first place?

Integration Approach

Stack fit

• Fits a standard Laravel + Filament application with no unusual infrastructure requirements: Composer 2, PHP 8.1+, and a Filament panel. spatie/laravel-package-tools implies package auto-discovery — no manual service-provider registration.
• The only stack-level addition is a Composer repository source. Everything else (database, queue, cache, hosting) is untouched.

Migration path

• From v1.2.1: no code migration, no data migration, no config republish required. Risk is confined to dependency resolution.
• Recommended path:
  1. Confirm question 1 above (Packagist availability) before writing any code.
  2. If the private registry is genuinely required, add the repository block to the root composer.json in a dedicated, reviewed commit — not implicitly via a transitive install.
  3. Validate in a clean CI container with an empty Composer cache to prove the build does not depend on a developer's local cache or prior lock file.
  4. Commit the resulting composer.lock and treat it as the reproducibility boundary.
• If the registry is not required (dependency is on Packagist), stay on v1.2.1 semantics and take v1.2.2 as a no-op patch.

Compatibility

• Backward compatible for existing installs: no API, no config keys, no view namespaces changed. Patch-level bump is appropriate.
• Forward compatibility is the open item — Filament major-version support should be confirmed before this becomes load-bearing in a production panel.

Sequencing

1. Discovery (now): answer the availability/licensing/ownership questions; inspect the package's and dependency's composer.json and license files directly.
2. Decision gate: adopt-with-registry, adopt-without-registry (if Packagist-resolvable), or defer on v1.2.1.
3. Mitigation build (if adopting with registry): stand up an internal mirror (Satis, Private Packistry, or equivalent) or vendor the dependency into a path repository, so our builds never depend on schemava.dev at CI time.
4. Pilot: one non-critical Filament panel in staging, clean-container build, one full deploy cycle.
5. Rollout: production, with the repository config and lock file change in a single auditable PR.
6. Governance: add the host to the approved-vendors list and to SBOM/license-scan exceptions if applicable.

Operational Impact

Maintenance

• Low ongoing code maintenance: presentation-layer plugin, no runtime services, no database footprint.
• New maintenance surface: a Composer repository entry that must be kept in sync, reviewed at each Composer upgrade, and re-validated whenever the maintainer changes registry hostnames. This is a small but permanent tax on every engineer who touches dependency resolution.
• The dependency chain now has two links maintained by the same author (filament-ummulqura-date-picker → ummulqura-calendar), so a single abandonment event takes out both.

Support

• No commercial support, no SLA, community/GitHub-issues only. Acceptable for a UI convenience component; not acceptable for anything on a critical path.
• Escalation for a broken release is effectively "pin the previous version and fork." We should be prepared to fork; confirm the license permits it (question 4).
• Internal support burden is documentation: a runbook entry explaining the registry, why it exists, and what to do when builds fail.

Scaling

• Registry latency is added to every composer update across all projects that inherit the config, not just this one. With warm caches the impact is negligible; on cold or degraded registry responses it can add tens of seconds to CI and to developer workflows.
• The repository is a single origin with no CDN guarantee stated. Under parallel CI fan-out (many jobs resolving simultaneously), this becomes a shared bottleneck and a shared blast radius.
• No horizontal-scaling concerns for the plugin itself — it is stateless, request-scoped, and CPU-negligible.

Failure modes

• Note also the "silent" failure mode: because the repository declaration inside the dependency has no effect on us, a teammate may reasonably read v1.2.2's release notes and conclude that installation "just works." It will not. That misconception is itself an operational risk and should be corrected in internal documentation.

Ramp-up

• Engineering ramp-up is minimal — roughly half a day to add the repository, run a clean-container validation, and document it.
• Review/governance ramp-up is the real cost: security and legal review of a new artifact source, plus an entry in the approved-dependency register. Budget one to two weeks of elapsed calendar time if a vendor-approval process exists.
• Recommendation: do not adopt v1.2.2 as-is on the assumption that it self-configures. Adopt it only alongside an explicit, root-level repository configuration plus a mirroring or vendoring mitigation — or defer on v1.2.1 until the dependency's distribution story is confirmed.