Validation Laravel Package

Product Decisions This Supports

• The build-vs-inherit question for validation. Validation is a table-stakes horizontal capability — every user-facing form, API payload, import pipeline, and admin CRUD screen needs it. The real decision this package informs is not "which validation library" but "do we hand-roll rules or inherit them from our framework."
• Feature scoping. If validation sits on the roadmap for onboarding, checkout, or self-serve admin tooling, this package represents one candidate implementation path: framework-native, version-aligned, no extra vendor in the dependency graph.
• Roadmap dependency mapping. Adopting marko/validation is only coherent if Marko Framework is already the platform. It is a [READ-ONLY] subtree split of the Marko monorepo — issues and PRs live upstream at marko-php/marko. There is no independent roadmap, no independent release cadence, and no maintainer surface to negotiate with. The product decision is really a framework decision wearing a package's clothes.
• Risk register entry. Zero stars, zero dependents, zero score. There is no observable production usage, no ecosystem, no third-party writeups, no CVE history. If this goes into a build, you are the first user — record that explicitly rather than burying it in a dependency review.
• Use cases it plausibly covers: request/form validation, API input contracts, config and tenant-settings validation, import/ETL row-level guardrails, and consistency of error messaging across surfaces.
• What it does not support: any decision on Laravel. See the next section — this is the single most important framing point.

When to Consider This Package

Consider it only if:

• You are already building on Marko Framework and want validation that stays idiomatically and versionally consistent with the rest of your stack. Using the framework's own component beats hand-rolling rule evaluation, nested-array traversal, and message formatting.
• You have a first-party-dependency preference — a compliance, security, or procurement review is materially easier to clear for a framework component than for an unvetted community package with no adoption.
• Your validation needs are conventional: required/type/length/format checks, nested structures, custom messages. Nothing exotic.
• You accept that support flows upstream to the Marko monorepo, not to this repo, and that your upgrade path is Marko's release train.

Look elsewhere if:

• You are on Laravel, Symfony, or Slim. Laravel ships Illuminate\Validation with Form Requests, Validator::make, custom Rule objects, and a very large ecosystem of community rules and localized messages. Adopting marko/validation on a Laravel codebase means adopting Marko — orders of magnitude larger than a validation swap. This is the decisive criterion and it disqualifies the package for most readers of this assessment.
• You need independent semantic versioning, a security-patch SLA, or a public vulnerability history.
• You need a rich rule ecosystem or community-contributed validators.
• You require observed production usage before adoption. Zero dependents provides none.
• You need standalone usage outside a Marko application — the split-repo structure signals this is not designed as a general-purpose library.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: "This is a component of a PHP framework, not a standalone library. It has zero stars and zero dependents, which means no external evidence of quality or production use. The only cost-justified reason to adopt it is if engineering has already committed to the Marko framework — in that case it's free, version-aligned, and better than hand-rolling validation. If we're on Laravel or any other mainstream framework, we already have comparable or better validation at zero incremental cost, and pulling this in would mean a framework migration disguised as a dependency choice. Recommendation: do not adopt as a standalone validation dependency."

For engineering — the working brief:

• It's a read-only subtree split. File issues and PRs at marko-php/marko. Budget for the fact that you cannot patch this repo directly and upstream responsiveness is unknown.
• Pinning a version means pinning to Marko's release train. Confirm the major-version upgrade story before you build on it.
• Run a one-day spike before any commitment: does it handle nested arrays, conditional/required-if rules, and custom error messages the way we need? How customizable is message formatting? How do we unit-test rules? What happens on a Marko major bump?
• If we're on Laravel: stop. Form Requests and the Validator facade already solve this, and the ecosystem around custom rules is deep. We would be trading a solved problem for a framework migration.
• If we're on Marko: use it, but keep validation rules behind a thin application-level interface so the framework component stays swappable if upstream stalls.