Date Picker Bundle Laravel Package

Technical Evaluation

The package is not a Laravel package. stnw/date-picker-bundle is a Symfony2 bundle with explicit SonataAdminBundle integration, so its architecture assumes Symfony's kernel, DI container, Form component, Twig templating, and Sonata admin conventions. A Laravel application has no compatible bundle/runtime surface; Composer may install files, but the service definitions, form types, and templates will not execute in Laravel.

Architecture fit: Very poor for Laravel. The only plausibly reusable layer is the client-side date/time picker JavaScript and CSS, plus perhaps a small amount of field-rendering logic that would need rewriting as a Blade component and Laravel validation rule. The PHP integration layer is Symfony/Sonata-specific and should be treated as non-portable.

Integration feasibility: Low. The package is effectively a Symfony2/SonataAdmin add-on, not a framework-agnostic PHP library. Direct Composer integration into a modern Laravel app is likely to create dependency conflicts or install unusable legacy Symfony packages. Extracting static assets is feasible only after license and provenance review.

Technical risk: High. Symfony2 is end-of-life, and SonataAdminBundle versions from that era are unmaintained. The package has zero stars, zero dependents, and a score of 0, which is a strong signal of abandonment and no community validation. The underlying JavaScript widget may carry outdated jQuery/Bootstrap dependencies, known CVEs, accessibility gaps, and CSP incompatibilities. Modern Laravel requires PHP 8.2/8.3 and Symfony 6/7 components; this bundle's constraints likely predate those.

Key questions:

• Which JavaScript date/time picker does the bundle wrap, and is that asset independently licensed and extractable?
• What are the Composer/PHP constraints, and do they conflict with the target Laravel version?
• Is the actual requirement a Laravel admin date field, or is there a hidden Symfony2/SonataAdmin system in scope?
• Are accessibility, i18n, timezone, and DST requirements defined?
• Is the "opportunity" score based on UI demand rather than package maintainability? If so, the opportunity is for a replacement, not this bundle.

Integration Approach

Stack fit: Poor as a package dependency. For a Laravel application, use a maintained Laravel-native field or a modern JavaScript picker integrated through Blade/Vite. Candidate replacements include Flatpickr, Tempus Dominus, or Pikaday, paired with Laravel validation (date, date_format, after_or_equal) and Eloquent casts. If the target is Filament or Nova, use the corresponding maintained field package.

Migration path: Treat this repository as a reference implementation, not a dependency.

1. Audit the bundle for the actual JS/CSS assets and license.
2. Port only the frontend widget into the Laravel asset pipeline if it passes security and accessibility review.
3. Reimplement the Symfony form type as a Laravel Blade component plus validation and timezone handling.
4. Replace SonataAdmin assumptions with the target admin panel's field API.
5. Remove the bundle from the Composer graph and document the replacement.

Compatibility: The bundle is built for Symfony2 and SonataAdminBundle; Laravel's service container, validation, Blade, and Eloquent are not compatible with Symfony2 form types or Twig templates. Twig templates would need rewriting to Blade, and Symfony form events/transformers would need equivalent Laravel request validation and model casting. PHP version constraints are likely a hard blocker for modern Laravel.

Sequencing: Start with a license and CVE audit of the bundled assets. Run a short proof of concept that extracts the picker into a Vite build inside a Laravel app. If the PoC exposes dependency, accessibility, or CSP issues, pivot immediately to a maintained JS picker. Implement Laravel-side validation, timezone/DST behavior, and persistence before removing the old bundle. Budget days for asset extraction and replacement, not weeks for Symfony2/Sonata integration.

Operational Impact

Maintenance: High if adopted as-is. The bundle is abandoned, so there is no upstream bug fixing, PHP 8 compatibility work, or security response. A TPM should assume fork-and-own ownership or replacement, not "install and forget." Owning a Symfony2 bundle inside a Laravel estate is a long-term liability.

Support: Essentially none. Zero stars and zero dependents imply no community, no vendor, and no external escalation path. Internal support would require rare Symfony2/SonataAdmin knowledge plus knowledge of the specific JavaScript widget. That is a poor support investment for a date picker.

Scaling: Package-level scaling is not meaningful because this is a form field. Operational scaling risk comes from spreading an unmaintained widget across many admin screens: every browser upgrade, CSP change, accessibility audit, or timezone requirement becomes a manual fix. Centralizing on a maintained picker limits that blast radius.

Failure modes: Composer dependency conflicts; class-not-found errors from Symfony2 form types; Twig/Blade template mismatch; jQuery/Bootstrap version collisions; asset pipeline breakage after Laravel/Vite upgrades; timezone and DST bugs in date-time selection; XSS or CSP issues from an old widget; and silent divergence between Symfony2 form behavior and Laravel validation.

Ramp-up: Low for extracting a static JS widget; high for maintaining the Symfony2/Sonata bundle. A Laravel team should not ramp up on Symfony2 for a date picker. The better ramp-up is a modern JS picker plus a Laravel Blade component, measured in days. The TPM recommendation is to avoid adopting the bundle as a dependency, reuse only vetted frontend assets if necessary, and otherwise replace it with a maintained Laravel-compatible field.