Validation Laravel Package

Technical Evaluation

Architecture fit. marko/validation is the validation component of the Marko framework, published as a read-only subtree split of marko-php/marko. It is architected around Marko's own service container, service-provider lifecycle, and configuration conventions. Laravel's validation stack, by contrast, is bound to Illuminate\Contracts\Validation\Factory, Validator, PresenceVerifier, facades, and the illuminate/translation package. The two are conceptually similar (rule sets, attribute translation, nested array validation) but structurally incompatible: there is no Laravel service provider, no facade, no publishable config, and no illuminate/* dependency surface to bridge against. Architecture fit for a Laravel codebase is therefore near zero for direct adoption and moderate only as a conceptual reference.

Integration feasibility. Technically possible in three shapes: (a) adopting Marko as the application framework — a non-starter for an existing Laravel product; (b) wrapping the component behind an internal adapter that satisfies our own validation contract, which requires rebuilding container wiring, translation loading, and error-message formatting that Marko would normally supply; (c) extracting individual rule implementations as reference code. Options (b) and (c) are feasible but shift most of the effort from "integrate a package" to "vendor and maintain a fragment of another framework." Because the repository is a read-only split, any defect we find must be fixed in the upstream monorepo and then flow back through a re-split — we cannot carry clean local patches without forking.

Technical risk. High relative to the value delivered:

• Bus factor / stewardship: 0 stars, 0 dependents, single upstream monorepo. There is no observable third-party usage to validate behavior under production load.
• Release hygiene: split repositories typically mirror monorepo tags without independent release notes or changelogs; version pinning semantics must be verified before any dependency is declared.
• Security posture: disclosure and CVE routing go through the parent repository, not this package; our security review process would need an explicit exception.
• Compatibility drift: the component evolves in lockstep with Marko core, so minor bumps may carry breaking assumptions about container contracts we do not implement.
• Documentation gap: guidance lives in the monorepo docs, not here; onboarding cost is understated by the package page.

Key questions.

1. What is the actual business driver — rule coverage, message formatting, or a specific validation feature Laravel lacks? If Laravel's validator already covers it, this evaluation ends here.
2. Does the component depend on marko/* core packages at runtime, and how tightly?
3. What is the upstream release cadence and backward-compatibility policy for the validation component specifically?
4. Are rule implementations self-contained enough to be lifted without dragging container or config dependencies?
5. Who owns a fork if we vendor it, and what is the exit plan?
6. Does the parent repository have a security policy, and can we subscribe to it?
7. What PHP version range is supported, and does it overlap our supported matrix?

Integration Approach

Stack fit. Poor. The component targets Marko's runtime; our stack is Laravel plus Composer with a curated dependency policy. There is no namespace collision with illuminate/validation only because the packages occupy different namespaces — that is not an integration path, it is coexistence. Adopting it would mean running two validation abstractions in one codebase, which is a maintenance tax with no offsetting capability unless a specific rule set is genuinely superior.

Migration path. Evaluate in ascending order of commitment and stop at the first that fails:

1. Reference-only (recommended default). Read the rule implementations, port anything materially better into our own Rule objects. Zero runtime dependency, zero operational exposure.
2. Vendored extraction. Copy specific rule classes into an internal packages/validation-rules with attribution preserved under MIT, rewrite against Illuminate\Contracts\Validation\Rule, and cover with our own tests.
3. Adapter integration. Only if the component exposes a stable, container-free API. Wrap it in an internal ValidatorAdapter implementing our existing contract, pin to an exact commit, and treat it as an internal fork from day one.

Full Marko adoption is out of scope and should be recorded as rejected.

Compatibility. Confirm the PHP constraint against our runtime, verify no marko/* runtime requirements leak in, and check whether the split ships a composer.json with autoload PSR-4 mapping that would conflict with our autoloader conventions. Because there are zero dependents, we cannot lean on ecosystem-tested version combinations; we must build that matrix ourselves.

Sequencing.

1. Spike (1–2 days): install in a scratch branch, exercise the documented API, inventory runtime dependencies and rule coverage.
2. Gap analysis: diff its rule set and message behavior against illuminate/validation; identify anything we actually need.
3. Decision gate: if the gap is empty or trivial, close as "no adoption." If non-trivial, proceed to extraction.
4. Contract tests: parameterized test suite covering each ported rule, run against both our current validator and the extracted implementation to prove behavioral parity.
5. Rollout: feature-flagged behind the adapter, shadow-validate production payloads for one release cycle before removing the flag.

Operational Impact

Maintenance. If we integrate rather than merely reference, we inherit ownership. The read-only split means upstream contributions require a monorepo PR plus a maintainer's re-split; in practice we will fork, which converts a dependency into a permanent internal project. Budget ongoing cost for upstream sync, patch reapplication, and PHP-version compatibility work. The reference-only path reduces this to near zero.

Support. No vendor, no SLA, no dedicated docs site, and an issue tracker that points elsewhere. Internal support means the engineer who did the spike becomes the named owner; without that, the integration becomes orphaned code. Escalation paths are essentially "fix it ourselves."

Scaling. Validation is CPU-cheap and stateless; throughput is not the concern. The scaling risk is coverage and correctness at breadth — a thin rule set means product teams write bespoke rules, which fragments validation logic across the codebase. There is also a localization scaling consideration: message translation depends on the host framework's translator, which we would have to wire ourselves.

Failure modes.

• Silent behavioral drift on upstream sync, producing different pass/fail outcomes for identical input.
• Missing integration with database-backed rules (exists, unique), forcing parallel implementations and inconsistent semantics.
• Unhandled exception types escaping as 500s instead of 422s if the adapter does not normalize error responses.
• Autoload or container-binding conflicts surfacing only in production boot order.
• Abandonment: no commits, no security response, and we discover it during an incident.
• Version resolution surprises if a future Laravel or PHP upgrade conflicts with pinned constraints.

Ramp-up. Superficially low — the API mirrors familiar validator patterns, so a Laravel engineer reads it in an afternoon. The real ramp-up is in the surrounding framework assumptions: container resolution, config shape, and translation flow, none of which are documented here. Expect the spike to look easy and the first production bug to be expensive. Plan for one engineer to hold context, and write an ADR capturing why we did or did not adopt before the knowledge decays.

Overall. On the evidence available — MIT license, zero stars, zero dependents, read-only split of a non-Laravel framework — the appropriate TPM recommendation is do not integrate; mine for reference. Adopting this as a runtime dependency introduces framework coupling and sole-maintainer risk that our product does not need. Revisit only if a specific, named validation capability is identified that illuminate/validation cannot deliver and that survives the contract-test gate.