Laravel Schema Rules Laravel Package

Product Decisions This Supports

• Build vs. buy for CRUD scaffolding. Every Laravel CRUD surface — admin panels, internal tools, customer-facing forms, API resources — needs a validation layer that closely mirrors the table. This package turns that from hand-written boilerplate into a one-line Artisan command (schema:generate-rules {table}), with an optional --create-request flag that emits a ready-to-edit Form Request class (including nested Api\V1\... namespaces). The buy decision is easy: MIT, dev-only, ~360 stars, actively maintained (Laravel 11/12/13 support shipping through v1.6.0), so the alternative is a few days of internal tooling that nobody will maintain.
• Estimating and de-risking "schema-first" features. When the roadmap includes a new entity (e.g., a persons-style record with strings, enums, FK, dates, nullable numerics), the generated rules give a concrete, reviewable artifact in minutes. That artifact is a useful estimating input: it exposes required vs. optional fields, max lengths, enum values, FK targets, and integer ranges before the form or API is built — surface area that usually gets discovered mid-sprint.
• Brownfield / legacy-database adoption. If we are wrapping an existing database in a Laravel service layer, this is the fastest way to get from "we inherited 40 tables" to "every table has a sane validation baseline." Strong fit for internal admin tooling over a legacy schema, data-migration review screens, and one-off back-office applications where perfect validation is not worth bespoke effort.
• Prototyping and API spike work. For proof-of-concept endpoints, generating rules from the actual schema removes a whole class of "validation says 255, column says 100" bugs during demo builds, letting the spike focus on the product question rather than the plumbing.
• Closing the DB-vs-application drift gap. The generated rules derive max from string(100), in: from column enums, exists: from FK constraints, min/max from numeric type ranges, and nullable from nullability. That makes database constraints and application validation start from the same source of truth, which is a real reliability win versus hand-typed rules that quietly rot as migrations change.
• Standardising how the team writes validation. Adopting it as a convention ("generate first, then fine-tune") gives reviewers a predictable baseline to diff against and reduces reviewer nitpicks about length/type rules in code review. skip_columns (defaults to created_at/updated_at/deleted_at) is the kind of small config knob that makes a convention actually stick.

When to Consider This Package

Adopt when most of the following hold:

• Greenfield CRUD velocity matters. We are shipping multiple similar resources and want a repeatable "migrate → generate → hand-tune" loop rather than bespoke validation each time.
• We are on MySQL, PostgreSQL, or SQLite. Those are the supported drivers. Note the README's own caveat: generated rules vary by driver because type ranges differ — so the rules are only as portable as the schema is.
• A "good baseline, then human review" workflow is acceptable. The package explicitly sells itself as a starting point. That fits teams with a review culture; it does not fit teams looking for a zero-review validation layer.
• The tables are conventionally shaped. Scalar columns, enums, FKs, nullables, standard timestamps. This is where the tool shines.
• We want a dev-only dependency with effectively zero production risk. composer require --dev means no runtime surface, no added attack surface, no deployment weight. The cost of trying it is a branch and an hour.

Look elsewhere — or treat it as a partial aid only — when:

• We need rules that stay in sync automatically at runtime. This is a generator, not a runtime binder. Once pasted into a Form Request, the rules are frozen; the next migration silently desynchronises them. If "validation always matches schema, forever" is a hard requirement, we need a different architecture (runtime introspection or schema-derived DTOs), and this tool becomes a stopgap.
• The schema leans on types the generator handles poorly. The README is candid: float, decimal, and double collapse to ['required', 'numeric'] with no precision or scale handling — a gap that matters for money, measurements, and anything financial. Plan for manual rules on those columns.
• We need business rules, not structural ones. Nothing here covers uniqueness-with-soft-deletes, cross-field conditionals (required_if, prohibited_unless), nested array validation, file uploads, or authorization — and no custom messages or attribute names. Form Requests will still need meaningful hand-editing; budget for it.
• We are on SQL Server or another unsupported driver. Not viable.
• Governance is strict about low-adoption dependencies. Packagist shows 0 dependents and the repository is a single-maintainer project with a modest star count. Mitigations are real (MIT, tiny surface, dev-only, removable in one commit), but for teams with strict supply-chain review, that conversation should be had up front rather than at PR time.
• The value is marginal. If we only ever write a handful of Form Requests, the setup + config publish + per-table invocation overhead is not obviously cheaper than just writing them.

How to Pitch It (Stakeholders)

The one-liner for executives: a small, free, developer-only tool that auto-drafts Laravel validation rules from our database schema, cutting the repetitive part of building forms and APIs while making validation start out consistent with the database.

The case in three points:

1. Speed on a recurring cost. Every new form or endpoint needs hand-written validation that mirrors the table — required fields, max lengths, allowed values, foreign-key existence, numeric bounds. A single command drafts all of it, and can emit the Form Request class directly. That is developer hours returned on every CRUD surface we build, not a one-off saving.
2. Fewer avoidable bugs. Hand-typed rules drift from the schema — a 255-character rule on a 100-character column, a missing exists: on a foreign key. Generating from the schema makes those mismatches structurally less likely at the start of a feature, which is where they are cheapest to prevent.
3. Low risk, low commitment. MIT licensed, installed as a development-only dependency (--dev), so it ships nothing to production. Actively maintained, with Laravel 13 support landing in the current release. If it disappoints, removal is one composer command — there is no migration, no runtime coupling, no vendor lock-in.

What to be honest about with engineering:

• It produces a baseline, not a finished rule set. Uniqueness, conditionals, nested payloads, authorization, and custom messages all remain manual work — it removes the tedium, not the thinking.
• Money and measurement columns are not handled well. decimal/float/double degrade to numeric with no precision or scale; those rules must be written by hand every time.
• Generated rules are a snapshot. They are copied into code, so they do not track later migrations. Whoever changes a column owns updating the rules — that is a process commitment, not a technical guarantee.
• Output varies by database driver, so rules generated on SQLite locally may differ from those generated against MySQL or PostgreSQL. Pick one canonical environment for generation.

Recommended framing of the ask: a timeboxed trial on one upcoming CRUD-heavy feature, with adoption judged on how much of the generated rule set survives review unchanged. If most of it survives, standardise on "generate, then fine-tune" as the team convention; if reviewers rewrite the bulk of it, we keep writing rules by hand and lose an afternoon.