Download the PHP package waleedhu/rules-to-schema without Composer
On this page you can find all versions of the php package waleedhu/rules-to-schema. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download waleedhu/rules-to-schema
More information about waleedhu/rules-to-schema
Files in waleedhu/rules-to-schema
Package rules-to-schema
Short Description Build JSON Schema from Laravel validation rules.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package rules-to-schema
Rules to Schema
Build JSON Schema from Laravel validation rules.
You already describe the shape of your data once, in validation rules. This turns that description into a JSON Schema, so you don't write it a second time to define an LLM tool, a structured output format, or an OpenAPI body.
Requires PHP 8.3+ and Laravel 13's illuminate/json-schema.
Usage
$schema is an Illuminate\JsonSchema\Types\ObjectType, so toArray() gives you a PHP array and casting to string gives you JSON:
Note that author itself is optional here, because no rule marks it required — but name and email are required within it if it is present. Add 'author' => 'required' to require the object too.
Reusing a form request
Rules live in a form request more often than in an array, and they work just as well:
Nesting and arrays
Dot notation becomes nested objects, and * becomes array items:
What gets mapped
Only rules with an exact JSON Schema counterpart.
| Rules | Becomes |
|---|---|
string, integer, numeric, boolean, array, list, decimal |
type |
required |
the parent's required list |
nullable |
"null" added to type |
min, max, size, between |
minLength/maxLength, minimum/maximum, or minItems/maxItems |
multiple_of |
multipleOf |
in |
enum |
regex |
pattern |
email, url, uuid, ipv4, ipv6, date |
format |
Bounds are resolved in the unit the type is measured in, the same way the validator sizes a value: min:3 is minLength on a string, minimum on a number, and minItems on an array. A field with no type rule is treated as a string, which is also how the validator sizes an untyped value.
What gets ignored
Anything without an exact counterpart is skipped rather than approximated, so the schema never claims a constraint the rules don't express:
- Rules with no equivalent, such as
confirmed,existsandmimes. ip, which accepts either version, so it matches neither theipv4nor theipv6format.ulid, because a ULID is not a UUID.- Rule objects, closures and invokable rules, whose logic isn't inspectable.
Testing
License
MIT.
