Nova Currency Laravel Package

Technical Evaluation

Assessment status: Initial assessment, created on publication of 0.1.0. Confidence is low — the release notes contain only "First Release," the prior evidence base is empty, and no package metadata, README, or changelog detail was supplied. The findings below are therefore structural (what a first 0.x release of a Laravel package implies) rather than package-specific, and should be re-validated against the actual repository before any commitment.

Architecture fit

• A Composer-installable Laravel package is a low-ceremony fit for a Laravel codebase, assuming standard conventions: a ServiceProvider registered via package discovery, optional facade, publishable config and migrations.
• None of that is confirmed. Whether the package is a thin wrapper, a driver integration, or something that reaches into the framework's internals materially changes the architectural verdict. This must be established from composer.json (require/require-dev constraints) and the package's directory layout before design work starts.
• Determine whether it is additive (new capability behind an interface) or invasive (overrides framework behaviour, registers global middleware, mutates the container). Additive packages are safe to trial; invasive ones need an ADR.

Integration feasibility

• Mechanically straightforward: composer require in a sandbox application, publish config, run the app's test suite. Realistic effort for a spike: 1–2 engineer-days if documentation exists, materially more if behaviour must be reverse-engineered.
• Feasibility is gated on dependency compatibility, not on effort. With no published constraint information, treat Laravel/Illuminate major-version compatibility, PHP version floor, and transitive dependency collisions as unknowns to be proven with composer why-not.

Technical risk — assessed high

• Semantic versioning at 0.x: under semver, anything may change in a 0.x minor bump. A jump from 0.1.0 to 0.2.0 can legitimately break the public API. This is the single largest risk and it is inherent to the version number, independent of code quality.
• No documented scope: "First Release" with no feature list, no known-issues section, and no compatibility matrix means there is no basis for scoping an evaluation.
• Maturity signals absent: no evidence of CI, test coverage, static analysis, or a security disclosure process. Absence of evidence is not evidence of absence, but at 0.1.0 the burden of proof sits with the package.
• Bus factor and longevity: first releases frequently come from a single maintainer with no stated support commitment. An abandonment scenario leaves the team owning a fork.
• Supply chain: a brand-new package with few installs and no review history warrants the standard hygiene checks — repository provenance, tag signing, dependency count.

Key questions to answer before adoption

1. What problem does this package solve that our own code or a mature alternative does not?
2. What are the exact illuminate/* and PHP constraints, and does the matrix include our current and next planned Laravel version?
3. Is the public API surface small enough to wrap behind our own adapter, so a fork or replacement stays cheap?
4. Does it ship migrations or modify schema? If so, is rollback supported?
5. Is there CI, a test suite we can run, and a stated support/security policy?
6. Who is the maintainer, what is the release cadence, and is there any signal of institutional backing?
7. Is there an upgrade guide or changelog process, or will every bump require a manual diff review?

Integration Approach

Stack fit

• Confirm the target Laravel major (8/9/10/11) and PHP floor against the package's composer.json before anything else. A mismatch here ends the evaluation cheaply.
• Verify test-tooling fit (orchestra/testbench major, PHPUnit/Pest version) so the package can be exercised inside our own test suite rather than only by hand.
• Check whether the package expects a specific driver, queue backend, cache store, or external service; any such coupling constrains where it can be deployed.

Migration path

• Treat this as greenfield only. Do not retrofit a 0.1.0 dependency into an existing critical path, and do not plan a migration from an incumbent solution until the package has survived a pilot.
• If there is an incumbent, run the package in parallel behind a feature flag and compare outputs before any cutover. Budget for the possibility that the parallel run is the end of the evaluation.

Compatibility

• Resolve the full dependency graph in a throwaway branch — not in main — and record the lockfile delta. A first release that forces transitive upgrades elsewhere in the app is a hidden cost.
• Check framework-adjacent surfaces explicitly: package discovery, config caching (php artisan config:cache), route caching, and queue worker restarts. Packages that misbehave under cached config are a recurring Laravel failure mode.

Sequencing

1. Static read (0.5 day): composer.json, README, LICENSE, tags, commit history, issue tracker. Decide go/no-go on the spike.
2. Sandbox install (1 day): fresh Laravel app at our target version, install, publish assets, run its tests and ours.
3. Compatibility proof (0.5 day): composer why-not, lockfile diff, config/route cache smoke test.
4. Adapter design (1–2 days): if viable, wrap the package behind our own interface so callers never touch its API directly. This is the primary mitigation for 0.x churn and should be non-negotiable.
5. Pilot (1 sprint): one non-critical service or a background job path, with the version pinned exactly and a dashboard on error rates.
6. Decision gate: promote, hold, or drop — with explicit criteria agreed before the pilot begins.

Operational Impact

Maintenance

• Assume every 0.x minor release is a potential breaking change. Budget a recurring review task per release: read the diff, re-run the test suite, re-validate the adapter. At an unknown cadence this is a standing, unbounded cost.
• Pin the exact version in composer.json and rely on Renovate/Dependabot PRs with CI as the review gate. Never allow a floating ^0.1 constraint.
• Assign a named internal owner. Unowned third-party dependencies are how teams discover breakage in production rather than in CI.

Support

• No support commitment, SLA, or LTS is implied by a first release. Internal support capability — the ability to read and patch the source — must be assumed as a requirement, not a fallback.
• Confirm there is a security disclosure route. If not, add the package to the internal vulnerability-watch list and track advisories manually.

Scaling

• Performance characteristics are entirely unknown. If the package sits in the request path, middleware stack, or a high-volume job, benchmark before promotion — a first release may carry N+1 queries, unbounded memory use, or blocking I/O where the app assumes async.
• Consider whether the package's data model scales with our data: packages that store state in a new table need an index and retention strategy from day one.

Failure modes

• Silent API break on a minor bump — mitigated by exact pinning and the adapter layer.
• Package abandonment — mitigated by keeping the adapter thin and the fork cost low; document the fork procedure.
• Transitive dependency conflict blocking a framework upgrade — the most likely long-term cost; surface it early via the lockfile diff.
• Behavioural drift under caching/queue restarts — caught by the cache smoke test in sequencing step 3.
• Undisclosed security issue with no advisory channel — accepted risk; record it in the risk register.
• Scope creep from undocumented behaviour — engineers building against reverse-engineered semantics; mitigated by writing the adapter's contract tests as the source of truth.

Ramp-up

• Low if the package follows Laravel idioms; the cost is not learning the API but learning its actual behaviour where documentation is absent. Expect the first engineer to spend more time reading vendor/ than the README.
• Produce a short internal note (half a page) recording the adapter contract and the pinned version rationale. This is what makes the dependency survivable through staff turnover.

Recommendation: proceed to the static-read and sandbox-install steps only. Do not approve for production on the strength of a "First Release" tag with no accompanying documentation; re-assess at the first minor version, when the maintainer's compatibility and changelog practices become observable.