- How do I install rpj/daterangepicker in a Laravel application?
- Install it with composer require rpj/daterangepicker, then publish the package assets and configuration with php artisan vendor:publish so the daterangepicker JavaScript and CSS land in your public directory. Because the package is small and has no CI or test suite, run the install on a scratch branch first and read vendor/rpj/daterangepicker/src and composer.json before wiring it into a production screen. That five-minute read also resolves what the package actually ships.
- Is rpj/daterangepicker a Blade component or a Laravel Nova filter?
- The repository description and README describe a generic Laravel Blade date-range component with publishable assets, configurable formats, locale and presets, while the release notes describe a Laravel Nova 4 filter. Those are different products with different integration points, so confirm whether the shipped class extends Nova\Filters\Filter, Nova\Fields\Field, or a plain view component. Do not plan a Blade integration until that ambiguity is resolved. Unresolved documentation conflicts are themselves a maturity signal.
- Which Laravel and PHP versions does rpj/daterangepicker support?
- The package has no stated support policy, so version support is whatever its composer.json constraints allow at the release you install. Run composer why-not rpj/daterangepicker against your Laravel and PHP versions before committing, and prove one screen end-to-end on staging rather than assuming compatibility from the README. The integration effort is measured in hours; the verification is the real cost.
- How do I render a date range picker inside a Blade form?
- The package exposes a Blade component with fluent, chainable options, so you drop the picker into your form and chain configuration such as locale, date format and predefined ranges instead of hand-writing the daterangepicker init script. Assets are published automatically, so you do not need manual script or stylesheet includes in your layout. Keep the input name stable so old-input binding and validation rules line up.
- How do I change the locale and date format of the picker?
- Localization and date format are part of the package's fluent configuration, so you set them on the component or in the published config file rather than editing the underlying JavaScript. Choose the display format and the server-side parse format together, because a mismatch between the two is a common cause of dates arriving as null. Document the chosen format so other developers do not reintroduce the gap.
- How do I repopulate the picker after a validation error?
- The component supports old-input binding, so it repopulates from the submitted value when validation fails and the form is re-rendered. Keep the field name identical between the picker, your validation rules and the controller read so the binding has something to resolve. Test the failure path explicitly, since a picker that renders but submits null fails silently.
- How do I read and validate the submitted start and end dates in PHP?
- The package is a UI adapter only, so you still validate the submitted start and end values with normal Laravel validation rules and parse them into Carbon instances in a form request or controller. Decide once whether the end date is inclusive of the full end day and which timezone the user's selection is parsed in, then document it, because the package enforces neither for you. Also confirm that the column you query is indexed.
- Can I customise the predefined ranges such as Last 7 Days?
- Predefined ranges are exposed through the fluent component options, so you can supply your own labels and boundaries instead of the defaults. If any range can produce an expensive query, cap the selectable range server-side as well, since whereBetween on an unindexed created_at column will full-scan. Treat the presets as a UX convenience, not as a validation boundary.
- What licence does rpj/daterangepicker use, and can I ship it in a closed-source product?
- The package is GPL-3.0, which is atypical in the Laravel and Nova ecosystem where MIT dominates. Internal admin-only use is usually fine for most teams, but it becomes a real problem on redistribution, on-prem appliances or client source handoff, so route it to legal before you build on it. This is a commercial decision rather than a technical one, and it gates everything downstream.
- Is rpj/daterangepicker maintained enough for production, or should I build the field myself?
- It has a single maintainer, zero dependents, no CI, no test suite and no stated support policy, and recent releases look like constraint-string bumps with no source changes. Its failure modes are silent: blank dropdowns, missing assets, filters that render but submit null, none of which throw. If diligent verification plus licence review exceeds roughly one to two days, building the equivalent field in-house is likely cheaper, so name an owner for this dependency on every major framework upgrade.