Schema Laravel Package

Product Decisions This Supports

• Feature scoping: declarative data schemas. Krak/schema models a schema as a first-class, introspectable object (type declarations, field definitions, processing rules) rather than ad-hoc arrays and isset() checks. This is directly relevant if you are scoping any feature where structured data must be defined once and reused across validation, hydration, serialization, and transformation — API request/response DTOs, import pipelines, configuration objects, or event payloads.
• Build vs. buy for an internal schema/DTO layer. The package is a reference implementation of the "schema as a value object" pattern. It gives you enough of a mental model to decide whether your team should standardize on a third-party schema library, hand-roll a thin internal abstraction, or lean on the framework (Laravel validation, Eloquent casting, Spatie Data). It is a cheap way to prototype the abstraction before committing engineering time.
• Roadmap: standardizing data contracts. If your roadmap includes API versioning, public data contracts, or cross-service payload consistency, the schema-declaration approach is a legitimate design input. Use it to pressure-test whether a schema registry / contract-first flow is worth investing in, and whether it belongs in-house or in shared libraries.
• Use cases to pilot: normalizing third-party webhook payloads before persistence; defining form/request shapes shared by backend validation and admin UI generation; parsing and coercing CSV/JSON imports against a declared structure; building internal "data dictionary" tooling where schema objects are enumerated at runtime.
• Risk triage for existing dependencies. With 1 GitHub star, zero dependents, and only a single pre-1.0 release after a long dormant period (v0.1.0, April 2020 → v0.2.0), this package remains a liability assessment (fork and own it, or replace it), not a capability assessment. v0.2.0 reinforces this: the first release in years is a breaking change to its core type model (struct vs. dict), which tells you the public API is still churning and no stability contract exists.
• Signal from v0.2.0 specifically. The changelog is two lines, one of which is a self-described BC break, and the other is an internal test fix for Symfony config fixtures. There is no migration guide, no deprecation path, and no documented upgrade notes — so upgrading is a manual, read-the-diff exercise. Weight the absence of a migration story more heavily than the presence of the change.

When to Consider This Package

Consider it when:

• You are prototyping a schema/DTO abstraction and want a concrete, small PHP implementation to reason about the API shape before you build your own.
• You need a framework-agnostic (non-Laravel-specific) declarative schema primitive and your context is internal tooling, a CLI, or a one-off data migration where maintenance and CVE exposure are acceptable.
• Your team is evaluating pattern libraries for a "define once, process everywhere" data model, and you want a comparison point alongside Symfony Serializer, Spatie Data, and Laravel's native validation/casting.
• You are willing to vendor/fork it at a pinned tag: because it is small and stable, vendoring v0.2.0 (not a floating constraint) inside your monorepo is a realistic option, and you accept full ownership of bug fixes, the struct/dict semantics, and PHP-version compatibility.
• You are specifically interested in the struct vs. dict distinction as a design question — what v0.2.0 clarifies is a real modeling decision (fixed-field records vs. free-form keyed maps) that most hand-rolled DTO layers get wrong, and it is worth an hour of design discussion even if you never install the package.

Look elsewhere when:

• The code path is customer-facing, security-sensitive, or must survive PHP/Laravel major upgrades — a dormant package that ships breaking changes on its first waking release offers no guarantees for PHP 8.x+ or modern framework versions without testing and likely patches.
• You need an actively maintained ecosystem: documentation, community support, security advisories, or a maintainer who responds to issues. One star and zero dependents mean no de-risking from third parties.
• Your stack is Laravel-first: prefer first-party primitives (Form Requests, validation rules, API Resources, Eloquent casts) or a maintained package such as Spatie Laravel Data, which gives you DTOs, validation, and transformation with real adoption and release cadence.
• You require performance at scale, streaming/large-payload processing, or async pipelines — a declarative library of this vintage is unlikely to be tuned for these.
• You need schema introspection for OpenAPI/JSON Schema generation; dedicated tools exist and are maintained.
• Any code already on 0.1.0. The struct/dict replacement is a BC break with no compatibility shim documented; treat migration as a rewrite of schema definitions and a full regression pass, not a version bump.

Adoption criteria checklist (all should be true to green-light): internal-only use case; fork or vendor pinned to an exact tag (v0.2.0, never a range) and owned by a named engineer; the v0.2.0 struct/dict BC break reviewed and its semantics accepted in writing; PHP-version compatibility verified in CI; a documented exit path to a maintained alternative; and no schema definitions crossing a public API boundary.

How to Pitch It (Stakeholders)

For executives (30 seconds): Krak/schema is a small, low-adoption PHP library for declaring and processing data schemas. Its new v0.2.0 release is a breaking change to its core type model with no migration guide — the first release in roughly five years, and it ships a BC break. That is a clear signal: no stability contract, no maintenance commitment, no security support, no community. Its value to us is as a design reference, not a component: it shows how to model schemas as reusable objects, which informs our build-vs-buy decision on data contracts and DTOs. Recommendation: evaluate, don't adopt; allocate a short spike, then standardize on a maintained option (Spatie Data or framework-native primitives) or a thin internal abstraction we own.

For engineering: Treat it as a pattern specimen, and read v0.2.0 in particular for the struct vs. dict distinction — that modeling split is the genuinely useful takeaway and worth reflecting into our own abstraction. Then discard the dependency. If we decide we want this style of API, we build ~200 lines internally or adopt Spatie Laravel Data — either way we keep ownership, tests, and PHP-version compatibility. If anyone proposes depending on it directly, the answer is no without a fork pinned to an exact tag, an owner, and a documented migration path; and if anyone is still on 0.1.0, flag it now, because the 0.2.0 type-model change is a manual port with no upgrade notes.

Key risks to state plainly: long-dormant maintenance with an unpredictable release cadence; a breaking change in the very first release after the gap, with no migration guidance; single-maintainer, near-zero adoption (no implicit QA from other users); unknown compatibility with current PHP/Laravel; no security response process. Opportunity framing: the problem space — declarative, reusable data schemas in PHP, including the struct-vs-dict modeling decision that v0.2.0 surfaces — is real and worth investment; this specific package is a weak vehicle for it.