- What does the rushing/laravel-data-schemas package do?
- It reads your declared Spatie Laravel Data classes and projects them into JSON Schema, so a single declaration can drive schema, documentation, and generated frontend types. The projection is a build-time step, not a request-path dependency, which makes it low-risk to trial and easy to isolate. The declared Data class is always the input, so it offers nothing for teams that still pass ad-hoc arrays or infer shapes from docblocks and runtime samples.
- How do I install rushing/laravel-data-schemas?
- Install it with Composer using composer require rushing/laravel-data-schemas, alongside spatie/laravel-data in a Laravel 10 or 11 application. Before committing, run a short spike to confirm whether the package publishes a config file, which artisan command or programmatic generator it exposes, and what output directory it expects. Then point it at your existing Data classes and generate a first schema to compare against your expectations.
- Which Laravel and PHP versions does laravel-data-schemas support?
- It is intended for a Laravel 10 or 11 codebase on PHP 8.1 or newer that already standardizes on Spatie Laravel Data. Exact version constraints are not clearly documented, so read the package composer.json to confirm the Laravel, PHP, and spatie/laravel-data bounds before adopting. Pinning those constraints in your own composer.json protects you from an upstream bump silently changing projection semantics.
- Does this package work with Spatie Laravel Data?
- Yes, Spatie Laravel Data classes are the input by design, which makes the output deterministic and reproducible from source. The tradeoff is tight coupling: the package reflects Spatie Data attributes and type resolution, and Spatie Data evolves quickly. Confirm which spatie/laravel-data version it was built against before you rely on the output.
- Which JSON Schema draft does it emit, and can I change it?
- The draft target is one of the key unknowns, so verify whether it emits draft-07 or 2020-12 and whether that is configurable. It also matters whether nested types are emitted as $defs or definitions referenced with $ref, or inlined everywhere, since that affects both payload size and how consumers resolve them. Treat this as a spike question rather than something to infer from the package name.
- How are nested Data objects, DataCollections, enums, unions, and Optional projected?
- Each of these needs an explicit mapping decision, and divergence is exactly where drift bugs live. Verify how nested Data classes and DataCollections are represented, whether enums become const or enum keywords, and how PHP nullability maps onto JSON Schema required. Optional and recursive types are the most likely to expose gaps, so cover them with fixtures before trusting the generated output.
- Can I generate schemas in CI and fail the build on drift?
- That is the natural use case, provided the generator produces deterministic, diffable output with stable key ordering. Confirm whether an artisan command or a programmatic generator API exists, since the available documentation does not clearly show either. If output is stable, commit the generated schemas and let CI diff them, turning schema drift into a reviewable pull request change.
- What happens to validation rules like exists, unique, or closures that JSON Schema cannot express?
- Rules such as exists, unique, database-backed Rule::in, and closure rules cannot be faithfully projected into JSON Schema. The risk is that they are dropped silently, which under-specifies validation and creates a false sense of correctness. Verify the behavior explicitly and, if rules are dropped, document it as a known gap and keep Laravel validation as the runtime source of truth.
- Is rushing/laravel-data-schemas safe to use in production?
- Conceptually it is low-risk because it is a build-time projection with no request-path dependency, so you can isolate it in a branch and remove it without runtime fallout. Maturity is the real risk: a single maintainer, roughly one star, and no known dependents mean you should expect to become the de facto maintainer if you adopt it. Keep it off the critical path unless you are prepared to fork and own it.
- Are there alternatives, and who maintains this package?
- The closest alternatives are hand-writing JSON Schema or going spec-first and generating code from the schema, but neither gives you one Data class declaration driving schema, docs, and client types. Maintenance is a single maintainer with little public signal on release cadence, issue responsiveness, or backward compatibility. Check commit history and open issues before adopting, and budget for a fork if you need it long term.