Date Inline Laravel Package

Getting Started

v1.0.16 is a patch release with date-input UX fixes and validation refinements; no breaking changes are called out. Treat it as a safe upgrade, but regression-test forms where start_date can be missing.

Start by checking the package README and changelog, then locate the package’s Blade date inputs, validation messages, and any publishable views/lang/CSS. First day-to-day use case: a form with optional start_date and end_date fields, e.g. reporting filters or booking/availability forms.

Minimal setup:

composer require <vendor>/<package>

Publish package assets only if you need to customize views, translations, or label styling. Use the package’s date input component or helper in Blade rather than hand-rolling date inputs, and keep validation in a Laravel FormRequest.

Implementation Patterns

Use the package inputs in create/edit forms and pass through old() values plus persisted model values:

{{-- Use the package's date input/component as documented --}}
{{-- Preserve old input and show package validation labels --}}

Keep server-side validation authoritative, even though v1.0.16 improves client-side date validation:

public function rules(): array
{
    $rules = [
        'start_date' => ['nullable', 'date'],
        'end_date' => ['nullable', 'date'],
    ];

    if ($this->filled('start_date')) {
        $rules['end_date'][] = 'after_or_equal:start_date';
    }

    return $rules;
}

In the save path, normalize a missing start date to null and avoid assuming it exists:

$validated = $request->validated();

$model->start_date = $validated['start_date'] ?? null;
$model->end_date = $validated['end_date'] ?? null;
$model->save();

If the package exposes its own save action, test it with both dates present, only an end date present, and neither date present. The v1.0.16 fix targets the missing-start-date case, but your controller should still be null-safe.

Customize validation labels through the package’s translation/view extension points where possible. For the new “Start Date is greater than End Date” label, verify the message appears in your locale and override it only if your product language differs. For label color changes, prefer overriding package CSS variables or published CSS rather than editing vendor files. Use autocomplete="off" as the new default behavior for package date inputs unless your product explicitly needs browser autofill; if so, override it deliberately in a published view.

Gotchas and Tips

• v1.0.16 fixes saving when start_date does not exist. Add regression coverage for create/update flows with a missing or nullable start date.
• The new date validation label may be translation-backed. Publish/override lang files if you need different copy, and check non-English locales.
• Label color changes can break visual snapshots or custom CSS specificity. Verify contrast/accessibility; don’t rely on color alone to communicate validation errors.
• autocomplete="off" is now applied to date inputs. This can affect browser autofill and user expectations; override only intentionally if your workflow depends on autofill.
• “Validate Date when the first digit are letters” is likely a frontend validation improvement. Do not remove server-side date rules; always validate dates in FormRequest or controller code.
• If you maintain custom views from an earlier version, compare them against v1.0.16 defaults for autocomplete, label color, and new validation messages.
• After upgrading, clear caches if published views/config/lang are involved: php artisan view:clear, php artisan config:clear.
• Debug by inspecting rendered HTML for autocomplete="off", checking the package version with composer show, and confirming which validation message source is active. Test reversed ranges, letter-prefixed input, and missing start dates explicitly.