Distribution Financings Laravel Package

Technical Evaluation

Architecture fit. This is a Laravel domain module, not a utility library. It ships publishable migrations, an (empty) config file, publishable views, and — based on the changelog ("Fixing Route API", "Update API") — an auto-registered HTTP/API surface. That means it does not sit beside your domain; it wants to own the donations, donors, financings, and programs tables plus their routes inside your application. Fit is therefore narrow: it suits a Laravel monolith in the zakat/amil charity distribution domain, and is a poor fit for anything with an existing donation or financing schema, a modular/microservice architecture, or a non-Laravel transactional core.

Integration feasibility. Installation mechanics are trivial (composer require, vendor:publish, migrate) and CI is healthy for a package of this size (PHPUnit, Pint, Psalm, Dependabot). The real cost is discovery, not installation. The README is the unmodified Laravel package skeleton: the description is still "This is where your description should go," the config file is literally return [];, and the only usage example is echoPhrase('Hello, ...'). None of that describes the actual domain. There is no endpoint reference, no model/relationship diagram, no event list, and no explanation of how financing, donation, funding_type, and program relate. The source code is the specification, which I would budget as a 1–2 sprint spike for one engineer before any commitment.

Technical risk — high. Concretely:

• Bus factor 1. Single maintainer (nadiannisaqilah), 0 stars, 0 dependents, no external consumers. There is no evidence this package has ever run outside its originating application.
• Semver is not respected. Release history shows schema and column changes in patch versions: donation_type → type (1.5.4), new columns funding_type_id/program_id (1.6.1), a new type column on donations (1.3.1), relationship refactors (1.7.1). Any composer update is a potential breaking change to our data and code.
• Schema coupling. Because it owns migrations, upgrading the package can mean altering production financial tables. That is a governance problem as much as a technical one.
• Route/config collisions. Auto-registered API routes and an empty config mean behavior is hardcoded — no prefix, middleware, or table-name knobs to negotiate with our app.
• Financial side effects. Version 1.2.2 "refund donation amount while deleting financing" implies destructive operations mutate balances. Without an audit trail, this is a compliance exposure.

Key questions for the maintainer (blocking).

1. What is the supported Laravel/PHP version matrix, and is there a deprecation policy?
2. Which routes are registered, under what prefix, with which middleware and auth assumptions? Are they disableable?
3. Does the package assume a specific user/tenant/organization model, currency, or accounting treatment (zakat vs. infaq vs. amil share)?
4. Are migrations reversible and safe on a populated database? Is there a table-prefix option?
5. Who is the internal consumer, what is their upgrade cadence, and can we obtain a named support contact?
6. Is deleting a financing still a hard delete with balance mutation, and is there an audit log?

Verdict. Conditional / do-not-adopt-as-dependency by default. Adopt only if (a) our domain model matches theirs almost exactly, (b) we are greenfield on these tables, and (c) we are prepared to fork and own the code. Otherwise treat it as a reference implementation.

Integration Approach

Stack fit. Standard Laravel: Eloquent models, migrations, service provider, artisan publish tags, MySQL-family database implied by the column-level changelog entries. Tests run via composer test; static analysis via Psalm suggests reasonable type discipline. Nothing exotic — no queue workers, no external services, no frontend build. The primary fit criterion is schema alignment, not framework version.

Migration path.

• Greenfield (new tables, our app has no donation domain): low friction — install into a branch, publish config/migrations/views, migrate, then immediately wrap the package's models behind our own repositories so the dependency does not leak into controllers and jobs.
• Brownfield (we already have donations/donors): this becomes a data-model transplant, not a package install. Expect table-name collisions, divergent column semantics, and a one-way mapping exercise. Plan for either an adapter layer with dual-write and backfill, or a fork with renamed tables/prefixes. Treat as a project, not a task.

Compatibility checks to run in the spike (in order).

1. composer.json constraints vs. our Laravel/PHP versions.
2. php artisan route:list diff — confirm no route-name or URI collisions.
3. php artisan migrate --pretend against a clone of our schema.
4. Publish and diff config/views — confirm the empty config truly exposes no knobs.
5. Static read of the models to reconstruct the domain diagram the README omits.

Sequencing.

1. Week 1 — Code audit spike (1 engineer): reconstruct models, relationships, routes, upload flow; produce the documentation upstream never wrote.
2. Week 2 — Isolated contract test: throwaway Laravel app, install, exercise donation → financing → delete/refund → upload paths. Measure query counts.
3. Week 3 — Decision gate: adopt-as-dependency vs. fork-and-own vs. reimplement. Default expectation: fork, because the release cadence is incompatible with a financial system's change control.
4. Week 4+ — Anti-corruption layer, then feature-flagged rollout or shadow-run against existing data.
5. Cutover only after a reconciliation report proves balances match the legacy system to the cent.

Operational Impact

Maintenance. Upstream is a byproduct of an internal application, so its roadmap serves that application, not us. Realistic steady-state: fork the repo, pin to a reviewed commit, and budget roughly 10–20% of one backend engineer for upstream merges, schema review, and security patching. Do not plan on composer update as a routine operation for a package that owns financial tables.

Support. No community, no issue-triage SLA, no documentation to fall back on, and commit messages in Indonesian — an underrated onboarding tax for an international team. Escalation is a direct conversation with the originating organization, which should be formalized in writing if this touches money movement.

Scaling. The workload is CRUD plus file upload (donation upload, financing upload) plus reporting queries. Likely hotspots: pagination on financing/donation lists (already patched twice — 1.2.4, 1.7.2), N+1 queries across the program/funding_type relations added in 1.2.0 and 1.6.1/1.7.1, and upload handling (validation feedback only landed in 1.7.12). Load-test list/report endpoints early; assume indexes need review since migrations are package-owned.

Failure modes to instrument.

• Migration drift on upgrade — a patch release alters a column we depend on. Mitigate with a migration lockfile and a CI job that diffs the published migrations against a reviewed baseline.
• Destructive balance mutation — financing deletion refunds donation amounts (1.2.2). Require an audit table or soft deletes before production use.
• Route collisions / unintended public API — auto-registered routes may expose endpoints we did not intend to publish. Verify middleware and gate them at the edge.
• Upload validation gaps — historically weak error surfacing; wrap uploads with our own validation and file-type/size limits.
• Silent reporting errors — the 1.2.3 "calculate amount remaining" fix shows arithmetic bugs reach release. Add reconciliation tests that assert totals against independently computed values.

Ramp-up. Installation: hours. Genuine competence: weeks, because the documentation gap means every engineer must read the models to learn the domain. Offset this by making the week-1 audit spike a permanent internal doc, and by keeping the anti-corruption layer thin enough that a future replacement of this package is a swap, not a rewrite.