Schema Validator Laravel Package

Technical Evaluation

Architecture fit. The advertised value proposition is sound in the abstract: declarative, reusable schema definitions that keep controllers thin and centralize validation rules across form requests, APIs, and console commands. That is a real problem in Laravel codebases, particularly ones with multiple entry points validating the same payloads. However, the fit assessment cannot be made on the marketing description alone, because the description is internally inconsistent. The repository metadata describes the package as "Validator check mapping array to DTO for Symfony", while the supplied documentation describes a Laravel bundle with a service provider, publishable config, and form-request integration. Those are two different products with two different integration surfaces. Until the actual composer.json and src/ tree are inspected, we do not have a verified statement of what this package does, which framework it targets, or whether the Symfony mention is stale text or the real scope. For a TPM this is the first gate: we cannot score architecture fit against an unverified API contract.

Integration feasibility. Mechanically, integration into a Laravel app is cheap if the Laravel framing is accurate — the documented path (pin the version, inspect the bundle, confirm provider discovery, publish config, resolve the container binding in tinker, wire one code path behind a config flag) is a standard half-day spike. The blocker is not effort, it is the dependency lifecycle. This package is archived, has a single release from August 2021, and sits at 5 stars. Archiving is not a code-quality signal, it is a support signal: there is no upstream to file bugs against, no one to accept a patch, no security response process, and no compatibility work for current PHP or Laravel. Any defect we find becomes permanently ours. That materially changes the buy-versus-build calculus regardless of how good the one release happens to be.

Technical risk. Ranked:

1. Framework compatibility (high). A 2021-era Laravel package is likely pinned to illuminate/* constraints from the Laravel 8/9 window and may not declare support for PHP 8.2/8.3/8.4. Laravel's major-version cadence means it is probably two to three majors behind. This is the most likely cause of outright install failure and the hardest to remediate without a fork.
2. SemVer instability compounded by abandonment (high). The 0.0.x constraint means the public API was never declared stable, so any internal assumption we bake into our code is unsupported. With a live maintainer this is a "wrap it" problem; with an archived repo it is permanent, so the wrapper is mandatory rather than advisable.
3. Evidence quality (medium-high). The supplied integration guide is a generic Laravel bundle template — note the literal vendor/package placeholders and the speculative "confirm auto-discovery registered the provider" steps. It describes a package, not this package. No verified service provider class name, config keys, container bindings, or contract interfaces have been provided. The description promises framework-agnostic core and Laravel integration; neither is evidenced.
4. Scope ambiguity (medium). The Symfony-vs-Laravel mismatch above. If the real artifact is a Symfony validator, Laravel integration is not an afternoon's work and the whole assessment resets.
5. Security and supply chain (medium). No maintainer means no CVE intake. The package is small and MIT, so the code is auditable, but auditing it is now a cost we own. Archiving also means we should verify the repo is genuinely read-only rather than a transient state.

Key questions — answer these before any commitment:

• Is schema-validator actually a Laravel package, a Symfony package, or a framework-agnostic core with both? The repository description and the supplied documentation disagree.
• What does composer.json declare in require for php, laravel/framework/illuminate/*, and symfony/*? Does it install cleanly against our current Laravel and PHP versions, or does it require --ignore-platform-reqs?
• Does the archive notice point to a successor package, a renamed repo, or the author's replacement library?
• What is the real API surface — interfaces bound in the container, or concrete classes only? Is there any tests/ directory or CI config at all?
• Does the package ship a published config we would own, and are its defaults production-appropriate or demo-tuned?
• Who is myaza-software — is there a live maintainer relationship we could establish (paid support, adoption of the fork upstream) or is this fully orphaned?
• What is the concrete overlap with Laravel's native validator and with maintained DTO-mapping libraries, and how much of the promised benefit survives if we simply write a base form request plus custom rules?

Provisional verdict. Do not adopt as a live dependency. The functional idea is worth stealing; the artifact is not worth depending on. Recommended posture: treat it as reference material (read the source, extract the schema-definition idea) and implement the equivalent with native Laravel validation plus a thin first-party seam, or evaluate a maintained alternative. If there is a specific piece of logic worth keeping, vendor it — copy the relevant classes into our own namespace under our own license headers and tests, so the archived repo stops being a runtime dependency.

Integration Approach

Stack fit. Assume a standard Laravel application (form requests, service container, queued jobs) on a currently supported PHP and Laravel version. The package's conceptual fit is good — schema-driven validation belongs at the form-request boundary. The version fit is likely poor, and that, not the concept, is the decision point. If our stack is Symfony rather than Laravel, the entire integration plan below is wrong and must be re-derived from the actual package.

Migration path. There is no migration path into this package in the SemVer sense — 0.0.1 is the first and only release, so any adoption is greenfield and any future change would be a fork rather than an upgrade. Conversely there is a clean path out: because the package is archived, we should design the integration as if we are already migrating off it. Concretely, do not let package types appear in our request classes, controllers, jobs, or resource layers. Define our own schema and validation contract, and keep the package behind a single adapter class that we could delete in one commit.

Compatibility. Two compatibility axes to verify on day one and record in the ADR:

• Install-time: composer require myaza-software/schema-validator:0.0.1 against our actual lockfile. If it requires relaxed platform constraints, that is a stop signal for a production path — relaxed constraints on a stale package in a modern runtime is how you get deprecation noise and, occasionally, an unpatched vulnerability.
• Runtime: whether the service provider auto-discovers, whether the config publishes, and whether the container binding resolves. Given the archiving, assume nothing is verified and lean on our own adapter tests rather than on any upstream test suite.

Sequencing (if leadership overrides the do-not-adopt recommendation and funds a spike):

1. Evidence gathering, no code. Clone and read composer.json, src/, and the service provider. Resolve the Symfony/Laravel scope question. Produce a one-page API surface note. Timebox: one day. This step alone will likely settle the decision.
2. Isolated install in a throwaway branch. Pin the exact version, commit the lockfile, confirm install against our real Laravel version. Do not merge.
3. Wrap before use. Create a first-party interface and adapter; bind it in AppServiceProvider. No package symbol escapes the adapter.
4. One shallow integration. A single form request or console command behind a config flag, exercised in staging, to observe real failure modes.
5. Write adapter tests and vendor the source if step 4 succeeds, so the archived repo is no longer a runtime dependency. At that point the "dependency" is our code and we have full control.

If at any point steps 1–2 require suppressing platform requirements, pinning an EOL Laravel version, or patching vendor code to boot, halt and fall back to the build-it-ourselves plan.

Operational Impact

Maintenance. This is the dominant cost. An archived repository means the maintenance burden transfers to us in full — no patch releases, no PHP or Laravel compatibility work, no dependency bumps for transitive advisories, no bug triage. Every line of the package we rely on becomes code we own without having written it. Budget it as such: if the adapter plus vendored source is ~500 lines, that is a permanent ~500-line ownership line item with no upstream, which is usually fine if it is explicitly accepted; it is never fine if it is invisible.

Support. There is no support channel. The 5-star count and 2021 last release indicate effectively no user base, so there is no community to search for error messages, no Stack Overflow corpus, no issue history to mine for failure modes. Internal debugging capability becomes the only support mechanism, which raises the on-call skill floor for anything touching validation.

Scaling. Validation is CPU-bound and stateless, so horizontal scaling is not a concern — the package will not be the bottleneck, the request path will. The scaling risk is organizational, not infrastructural: the cost of this dependency grows with the number of code paths that reference it, and it shrinks only via deliberate refactoring. Because the package is archived, that growth is one-directional unless we enforce the adapter seam from day one. Schema definitions, if stored as PHP arrays or config, will also grow into a de-facto DSL that only one or two engineers understand — plan for documentation of the schema vocabulary, not just the code.

Failure modes to watch:

• Silent provider non-discovery. Package classes resolve, but config is empty or expected behavior is absent. Check php artisan about and the provider list first.
• Config cache divergence. Published config edits appear to do nothing locally until config:clear; in production the deploy pipeline must run config:cache after the config file lands. On an unmaintained package, a config key rename between environments is an unrecoverable silent break.
• Platform-constraint drift. A dependency declared to support PHP 8.0 and Laravel 8 will not announce its own obsolescence; it will fail on a PHP minor bump during an unrelated upgrade, and the failure will surface in a deploy rather than in a test, because no upstream CI is watching for us.
• Error-message contract changes. Validation error payloads frequently leak into API contracts and front-end parsing. If we ever move off the package — which, being archived, is the expected path — the message structure must be preserved by our adapter or downstream clients break.
• Unpatched security advisory with no notification path. Nothing will tell us a transitive dependency of this package is vulnerable; our own SCA scanning is the only signal.

Ramp-up. Low learning curve for the concept, high for the operational caveats. An engineer can be productive with the validation API in under a day if the documentation is accurate; getting them to the point where they understand why the adapter seam exists, why the version is pinned exactly, and why they must not call the package directly from a controller takes a deliberate briefing and a written ADR. New hires will otherwise reasonably assume an archived package is fine because it "still works." Record the decision, the rationale, the accepted risks, and the exit plan in the ADR, and set a review date — a decision to adopt an archived dependency should be revisited at the next framework major upgrade, at the latest.