Schema Laravel Package

Product Decisions This Supports

• Build vs. buy for data-integrity plumbing. Schema validation for config and payloads is solved, undifferentiated work. Adopting nette/schema converts a recurring "write bespoke validation for this new integration" line item into a small, maintained dependency — freeing engineering capacity for roadmap features instead of validation internals.
• Configuration safety as a reliability lever. Most config-driven incidents (bad env values, malformed YAML/JSON, type coercion surprises) surface at runtime, far from the cause. Declarative schemas with dot-path errors (database.host) move those failures to bootstrap, where they're caught in CI or at deploy rather than in production traffic.
• API contract enforcement for external-facing surfaces. For webhook ingestion, partner integrations, and JSON API endpoints, schema definitions become an executable contract: required fields, types, defaults, and coercive normalization in one place. This supports decisions about API versioning and backward compatibility, because the schema is the artifact you diff between versions.
• Typed DTOs reduce the cost of new features. castTo() lets validated payloads land directly in domain objects, which shortens the path from "new endpoint" to "shippable" and shrinks the class of bugs caused by loosely-typed arrays flowing through the codebase.
• Roadmap enablers: config layering per environment (merge() / extend()), deterministic config output for caching/diffing (skipDefaults()), and machine-readable error codes (required, type.string) that make localized, frontend-safe error messaging a configuration task rather than a code task.
• Portfolio hygiene. A ~1k-star, actively released (current release dated 2026-08-17), PHP 8.1+ library with PHPStan-level-9 discipline is a low-risk borrow. The trade-off to accept explicitly: it is framework-agnostic, so we own the Laravel glue (no first-party service provider, zero Laravel dependents in the ecosystem). That glue is small, but it is our maintenance surface — budget it as an internal package, not as a fire-and-forget dependency.

When to Consider This Package

Adopt when:

• You have complex, nested, or dynamic data structures — multi-level config, layered environment settings, nested API payloads — where Laravel's Validator rules become an unreadable array of dot-keys and wildcards.
• You want normalization, not just rejection: defaults filled in, 'TRUE' coerced to true, validated output shaped into DTOs.
• Failures need precise, structured, localizable errors (path + error code) rather than a flat bag of strings.
• The team is on PHP 8.1+ and values static analysis; schema misuses can be caught in CI before runtime.
• The data is a contract you own and version (config files, internal service payloads, partner ingestion) rather than end-user form input.

Look elsewhere when:

• The need is HTTP form validation with Laravel's conventions — FormRequest, authorize(), redirect-with-errors, and Blade error bags. Keep Laravel's Validator for that; layering two validation systems on one endpoint is a maintenance tax, not a feature.
• You need JSON Schema interop (third-party schemas, OpenAPI generation, schema sharing across language boundaries) — an explicit JSON Schema implementation will serve better than a PHP-DSL.
• You're on PHP 8.0 or below, or on a legacy Laravel version without a clean upgrade path.
• You require vendor-backed support, SLAs, or a large first-party Laravel integration surface. There is none here; the trade is maturity and stability for ecosystem gravity.
• The validation is trivial (one or two scalar fields). The schema DSL is worth its learning curve only once structures nest or repeat.
• License needs legal sign-off. The repository reports NOASSERTION, which typically means GitHub could not auto-detect a standard license file. Confirm the actual terms (Nette libraries are generally BSD-3-Clause) before it enters a distributed or commercial product — this is a one-hour legal check, not a blocker, but do it before the sprint, not after.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: We handle a growing amount of configuration and inbound data from systems we don't control, and our current approach validates it ad hoc, in code written per integration. That's slow to build and slow to debug: bad values surface as runtime failures far from their source. nette/schema is a small, mature, actively maintained PHP library that lets us declare the shape of that data once and enforce it automatically — catching problems at deploy time instead of in production, and removing validation boilerplate from every new integration we ship. It's a buy-not-build decision with a modest footprint and a clear failure mode: if it disappoints, the schemas are plain PHP and can be replaced incrementally. Two asks: confirm the license terms, and fund a small internal wrapper so the integration stays consistent across teams.

To engineering — the summary: Declarative schema validation for nested PHP data, framework-agnostic, PHP 8.1+, current release dated 2026-08-17, static-analysis-clean. We use it for config bootstrapping and non-HTTP payload contracts; we keep Laravel's Validator for user-facing form requests and don't mix the two on one endpoint. What we get: defaults and normalization, structured errors with dot-path context and stable error codes, castTo() for DTO mapping, and merge()/extend() for environment-layered config. What we take on: we write and own the Laravel glue (service provider, config-loading hook, error-code-to-message mapping) as a thin internal package; there's no first-party Laravel support to lean on. Known traps to encode in our wrapper so nobody rediscovers them: Expect::array() vs. listOf() (silent key stripping on lists), defaults not applying to explicit null, and AnyOf([]) throwing. One prerequisite: a short legal check on the NOASSERTION license designation, and a decision on PHP 8.1 as a floor if any service is still below it.