Laravel Schema Rules Laravel Package

Technical Evaluation

Architecture fit. The package is a developer-time code generator, not a runtime library. It is installed with --dev, exposes a single Artisan entrypoint (schema:generate-rules), introspects the live database schema, and emits either a copy-pasteable array of Laravel validation rules or a full Form Request class. That places it squarely at the seam between the persistence layer (migrations/schema) and the HTTP validation layer (Form Requests), which is exactly where hand-written validation rules most often drift out of sync with reality. It does not touch the request lifecycle, does not register middleware, and — because it is a dev dependency — should never be present in a production image.

The conceptual value is defensible: the database schema is already a machine-readable statement of type, nullability, length, and range constraints, and the package converts that into the required|string|min:1|max:100 dialect developers already write by hand. It fits the Laravel idiom rather than fighting it.

Integration feasibility. Low effort. composer require --dev, publish one config file, run one command. No migrations, no service provider toggles in production, no queue, no external service. The README is complete enough to run without reading source. Supported drivers are MySQL, PostgreSQL, and SQLite, and Laravel 13 support landed in 1.6.0, so the compatibility window is current.

Technical risk. The risk is not operational — it is correctness ceiling, and it matters because generated rules look authoritative while being explicitly "a starting point."

• Precision loss is documented and real. float, decimal, and double collapse to ['required', 'numeric']. For a price, balance, or tax column, that means no scale check, no precision bound, and no protection against values the column cannot store. This is the single largest hazard for financial or billing domains.
• Nullability ≠ requiredness. The generator infers required from NOT NULL. That is a storage constraint, not a statement that the client must submit the field. Generated rules are store-shaped; running --create-request --file UpdatePersonRequest yields the same rules, so a PATCH endpoint will demand every non-nullable column unless a developer manually downgrades to sometimes. This is a predictable review failure.
• Referential rules are naive. Foreign keys become exists:addresses,id, with no awareness of soft deletes, tenant scoping, or global scopes — so a soft-deleted or cross-tenant parent can pass validation and fail at the application layer, or worse, succeed at the database layer.
• Enum coupling is silent. in:m,f,d is generated from the column definition, but nothing re-runs when a migration adds a value. Drift is invisible until a legitimate request is rejected.
• Driver-dependent output. The README states rules vary by driver. A team developing on SQLite and deploying on PostgreSQL will generate different rules in different environments unless generation is pinned to the canonical driver.
• Coverage gaps to verify explicitly. The docs do not advertise unique rule emission from unique indexes, composite key handling, or JSON schema validation. Treat these as absent until proven otherwise in a spike.
• Bus factor and ecosystem signal. 362 stars, zero dependents, effectively single-maintainer, dependency-bump-heavy changelog. Small blast radius, but also little third-party soak-testing of edge cases.

Key questions for the team.

1. Do we run generation on developer machines only, or in CI? If CI, is a database available at that stage?
2. Which tables carry money, rates, or quantities where numeric alone is insufficient?
3. Is the application multi-tenant, and do any foreign keys point at soft-deletable models?
4. Which driver is canonical for generation, and does it match production?
5. Do we commit generated Form Requests as source of truth, or treat output as a scratchpad?
6. Where is the migration → regenerate → diff-review step enforced in the PR process?

Integration Approach

Stack fit. Best fit is a Laravel application that already uses Form Requests as its validation boundary and has a schema-heavy, CRUD-oriented surface: admin panels, back-office tools, internal APIs, or a greenfield domain being scaffolded. It fits poorly where an OpenAPI/JSON Schema contract is already the source of truth (duplicating generated rules creates a second, weaker contract), or where validation is deliberately hand-tuned per endpoint with authorization-aware rules.

Migration path. Strictly additive. No schema change, no data change, no runtime code path. The package is adopted by a single commit and removed by a single commit, and removing it leaves every generated Form Request intact and functional — generated code is ordinary Laravel code with no package dependency. That gives a genuinely free trial.

Compatibility checks before adoption. Confirm the pinned Laravel and PHP versions against the 1.6.0 release; confirm the DB driver and server version (there is a historical MySQL 5.8 fix in 1.3.1, suggesting engine-version sensitivity); confirm whether introspection needs a live connection in the target environment (it does — this affects containerized and CI setups); and confirm the driver used locally matches the driver used in staging.

Sequencing.

1. Add as a dev dependency, publish schema-rules-config, and extend skip_columns to the org's conventions (uuid/ulid keys, tenant_id, timestamps, any audit columns).
2. Pilot on one or two low-risk tables. Diff the generated output against existing hand-written rules — this calibrates the team's intuition about what to keep and what to delete faster than any documentation.
3. Adopt --create-request for store requests only. Hand-author update requests, starting from generated output but converting non-nullable columns to sometimes.
4. Write down the deletion checklist: strip min:1 on strings, replace numeric with decimal:n,m on money columns, add unique where indexes exist, scope exists rules where tenancy or soft deletes apply.
5. Make regeneration repeatable — a Composer script or Make target per bounded context — so it is a ritual rather than a one-off experiment.
6. Do not gate CI on generated output matching committed files. The generator's value is scaffolding; enforcing byte-equality would freeze the hand-tuning the README explicitly asks for.

Operational Impact

Maintenance. Runtime maintenance burden is effectively zero — nothing ships to production, so there is no failure surface, no upgrade pressure mid-incident, and no security exposure from the dependency itself. What remains is process maintenance: a small, single-maintainer upstream that must be version-pinned and whose changelog should be skimmed at each Laravel major. Dependency-bump-dominated releases are a mild signal of low feature velocity, which is acceptable for a utility of this scope.

Support. MIT, no SLA, small community. The mitigation is unusually strong: the exit path is "write the rules yourself," which is what the team was already doing. This is close to the lowest-support-risk dependency category available.

Scaling. Cost scales with table count and team size, not with traffic. Ten tables and one team: ad hoc generation is fine. Fifty tables and four teams: without a shared skip_columns convention and a written post-generation checklist, generated rules will diverge stylistically and semantically across squads, and the tool becomes a source of inconsistency rather than a cure. The scaling lever is a short internal convention doc, not tooling.

Failure modes to watch.

• Stale rules after migration — the highest-frequency failure; a column widens or an enum gains a value and validation silently rejects valid input or accepts invalid input.
• Precision loss on decimals — accepts values the column cannot store; surfaces as a database error or silent truncation at write time, i.e. far from the validation layer.
• exists on soft-deleted or cross-tenant parents — validation passes, downstream logic fails or leaks.
• Over-strict update requests — PATCH clients forced to send full payloads.
• Driver divergence — rules generated on SQLite differ from what PostgreSQL enforces; caught only in staging.
• Regeneration overwriting hand-tuning — --force on --create-request will clobber reviewed, hand-edited rules. Treat --force as a local-only flag and never wire it into automation.

Ramp-up. Very low. The README is complete, the command surface is four flags, and a mid-level Laravel developer is productive in under half a day. The training that actually matters is judgment, not mechanics — teaching developers that generated output is a first draft that must be edited for requiredness semantics, numeric precision, uniqueness, and referential scoping. Budget a short brown-bag and a checklist in the repo, and the tool pays for itself on the next CRUD module. Skip that, and it becomes a fast way to produce confidently wrong validation.