Laravel Schema Generator Laravel Package

Getting Started

This package bridges Laravel's server-side validation rules and the browser: you declare rules once (typically in a FormRequest), the package emits a generated artifact the front end consumes, and the browser enforces the same constraints before submit. v1.0.14 fixes the relative-date case, so it's the release to start on if you have any before: / after: rules.

Minimal path:

1. Install via Composer and publish the package config. Confirm the output path for generated files and where the JS/JSON artifact is served from.
2. Put a single date rule in a FormRequest — e.g. 'start_date' => ['required', 'date', 'before:+1 week'].
3. Run the package's generation command and inspect the emitted file. After v1.0.14 the relative rule should appear as a dynamic limit (evaluated in the browser at validation time), not a frozen timestamp.
4. Load the generated file on the page, submit a date outside the window, and confirm the browser blocks it — then confirm the same request is rejected server-side when posted directly.

First real use case: a booking or scheduling form with a "must be within the next N days" constraint. This is precisely the scenario the release targets.

Implementation Patterns

Single source of truth for rules. Keep rule definitions in FormRequest classes and regenerate the artifact as part of your build/deploy pipeline. Because v1.0.14 makes generated files stable, regenerating no longer produces spurious diffs just because time passed — you can commit generated output and review it meaningfully.

Relative rules belong in the browser, static rules don't. Use before:+1 week, after:-30 minutes, before:now+2 days, etc. for windowed constraints. Keep absolute dates (before:2025-12-31) as literals — they're stable by nature and there's no reason to defer them.

Signed offsets you can rely on: seconds, minutes, hours, days, weeks, with an optional now prefix. Prefer explicit units (+2 hours over +120 minutes) only when it reads better; both work.

Timezone discipline. Set app.timezone to UTC (or at minimum ensure the validation timezone is UTC). Days and weeks are treated as elapsed durations, so a "week" is not a calendar week across a DST boundary. UTC makes PHP and browser limits agree exactly. If your app must run in a local timezone, expect sub-hour drift around DST transitions and treat the server as authoritative.

Test at both layers. In PHPUnit, assert the generated artifact contains the expected dynamic expression (not a resolved timestamp), and separately assert the server accepts/rejects the right values. Avoid asserting on exact epoch values for relative rules — they legitimately move.

Pair with server-side validation always. The browser check is UX; the FormRequest rule is the guarantee. Never let the generated file be the only enforcement.

Gotchas and Tips

• Regenerate after upgrading. The fix changes the shape of generated output for relative rules. Existing artifacts built by earlier versions contain frozen dates that will silently drift out of sync with the PHP rule. Re-run generation and commit the result.
• "Stable files" ≠ "static limits." The generated file no longer embeds a computed timestamp; the limit is calculated during validation. Don't write tests or tooling that expect the file to change over time — and don't expect it to encode a fixed cutoff either.
• Client clocks lie. A user's device clock can be skewed by hours. Relative rules evaluated in the browser inherit that skew. For anything security- or money-sensitive, validate against server time and consider surfacing a clear message rather than a silent rejection.
• Days/weeks are durations, not calendar units. +1 week means seven elapsed days. If you need "same weekday next week," that's not what this expresses.
• CDN/cache invalidation. If the generated artifact is served through a CDN or has a long cache TTL, version the filename or bust the cache on deploy — otherwise clients keep running a stale rule set after you change a FormRequest.
• PHP 8.5 deprecation notices are still present. They're not fatal, but they will pollute logs and can fail CI if you treat deprecations as errors. Either pin the deprecation handler for this package's namespace or track the upstream fix.
• Debugging mismatches: when browser and server disagree, first check timezone config, then check whether the artifact was regenerated after the last rule change, then check for client clock skew. Those three account for nearly every discrepancy.
• Extension point worth knowing: the rule-to-client mapping is where you'd hook in custom validation rules that aren't natively supported. If you have domain-specific date logic, express it as a relative rule if possible rather than adding a bespoke mapping — you'll get the dynamic-evaluation behaviour for free.