Datetimepicker Bundle Laravel Package

Technical Evaluation

Architecture fit — critical mismatch. The request frames this as a Laravel/PHP package, but stephanecollot/datetimepicker-bundle is a Symfony bundle, not a framework-agnostic library and not a Laravel package. It ships Symfony form types, Twig form themes, and bundle registration (AppKernel-era conventions). It contains no Laravel service provider, config publish tag, facade, Blade view, or illuminate/* dependency. Dropping it into a Laravel composer.json yields no usable integration surface — the value would have to be re-implemented, not installed.

Integration feasibility. Two distinct verdicts:

• Laravel target: Not feasible. There is nothing to integrate. A "port" means writing a Blade component, a validation rule, and asset wiring around a JS picker — at which point the bundle contributes no code you would keep.
• Legacy Symfony target (≤3.x, jQuery, Bootstrap 3): Feasible but only as frozen legacy surface. Modern Symfony (4+/5+/6+/7) removed the bundle conventions and Twig form-theme hooks this package relies on; Composer constraints will not resolve against current symfony/form and symfony/framework-bundle.

Technical risk — high, concentrated.

• Abandonment risk: Single maintainer, no release since 2017, no CVE-response path, no upstream triage.
• Transitive frontend debt: The underlying picker lineage (Bootstrap 3 DateTimePicker / Eonasdan lineage, jQuery, moment.js) is itself archived/deprecated. You inherit two layers of unmaintained code.
• Runtime risk: PHP 8.x and modern Symfony are untested and unsupported; deprecation removal will break it silently.
• Asset pipeline risk: Bundle-era asset inclusion (Assetic-style publishing) conflicts with Vite/Webpack Encore in current Laravel and Symfony stacks.
• Score interpretation: A 7.77 composite with opportunity: 10.81 on a 56-star, 0-dependent, 8-year-stale package reads as a static-signal artifact (permissive license, clean metadata, unclaimed niche) rather than validated demand. High "opportunity" on a zero-adoption package usually means no market, not open market. Do not let the numeric score drive the decision.

Key questions for the requester.

1. Is there an actual Laravel application in scope, or is this a mislabeled Symfony legacy inventory item?
2. If Symfony: what exact versions are in composer.lock, and is the app already on jQuery + Bootstrap 3?
3. Is there any installed instance today, or is this greenfield consideration? (0 dependents on Packagist suggests greenfield.)
4. Who owns the datetime UX requirement — is it a picker widget need or a timezone-aware datetime model need? These have very different solutions.
5. What is the maintenance horizon of the host app? If it is being sunset, pin-and-freeze is acceptable. If it is a growth product, this is a non-starter.
6. Would a native <input type="datetime-local"> or a maintained picker (Flatpickr, Tempus Dominus) satisfy the requirement?

Integration Approach

Stack fit. Effectively zero for Laravel 9/10/11 on PHP 8.1+. Conditional fit only for a Symfony 2.3–3.x application already using jQuery and Bootstrap 3, where the bundle is already installed and merely needs to keep running.

Migration path (recommended: replace, don't integrate). The pragmatic route is to treat this as a replacement program, not an adoption:

1. Audit. Search composer.json/composer.lock and the codebase for DatetimepickerBundle, datetimepicker form type usage, and jQuery/Bootstrap 3 asset dependencies. Establish whether anything is actually installed.
2. Requirement extraction. Document the real UX needs: date-only vs datetime, timezone handling, min/max ranges, locale/format, mobile/touch, accessibility (WCAG), validation coupling.
3. Prototype replacement. In Laravel: a Blade component wrapping a maintained picker (Flatpickr or Tempus Dominus) plus a FormRequest validation rule for the datetime format, plus a small JS entry in Vite. Estimate 3–5 engineering days including tests.
4. Sequence by surface area. Migrate highest-traffic forms first, run old and new in parallel behind a feature flag if the form is revenue-critical.
5. Decommission. Remove the bundle and the jQuery/moment.js transitive dependencies; confirm bundle size reduction.
6. Regression guard. Add browser-level tests for the picker interactions (open, select, clear, mobile viewport, keyboard-only) — this is the class of bug that silently regresses.

Compatibility work, if someone insists on the legacy path. Expect Composer constraint conflicts against modern symfony/*. Do not resolve these with --ignore-platform-reqs or widened constraints; that produces an untested runtime and shifts risk from install-time to production. The correct legacy move is version pinning plus an explicit "do not upgrade" note in the app's technical debt register.

Sequencing note for the TPM. There is no meaningful "pilot" for a package with zero dependents and no release in eight years — there is no peer evidence to lean on. Budget the effort as internal build, and gate the decision on question 1 above (Laravel vs. Symfony) before any engineering time is spent.

Operational Impact

Maintenance. Effectively unmaintained. No releases since 2017, no security response process, no compatibility work for PHP 8 or current frameworks. Any defect becomes yours to fix in a codebase whose conventions no longer match the host framework. The practical maintenance model is vendored fork with an internal owner, which is a permanently staffed commitment for a UI widget.

Support. No vendor, no SLA, no active issue triage. 56 stars and 0 dependents means no community to escalate to and no signal that someone else has hit your bug. Knowledge is concentrated in one historical maintainer. Internal ramp-up cost is asymmetric: hours to use, weeks to own.

Scaling. Not a backend scaling concern — the bundle is a form widget, not a data path. The scaling cost is frontend payload and dependency drag: jQuery plus moment.js plus picker CSS adds tens of KB per page without tree-shaking, and pins the host app to a legacy asset pipeline. On a large Laravel app, that is a recurring tax on every page load and a blocker for adopting Vite cleanly.

Failure modes to plan for.

Ramp-up. Low to consume, high to inherit. A new engineer can wire the form type in an afternoon on a legacy Symfony app; the same engineer will spend considerably longer reverse-engineering why it breaks under a framework or PHP upgrade, with no upstream documentation or maintainer to consult. Onboarding documentation should explicitly state the package is frozen and the replacement path is X.

TPM recommendation. Reject for any Laravel scope — the package is structurally inapplicable and the numeric score is not a reliable signal at this adoption level. Tolerate only as frozen legacy in a Symfony 2/3 application that is already sunsetting. Where a datetime picker is genuinely needed, fund a small internal Blade component around a maintained picker: it is a few engineering days, removes two layers of abandoned dependency, and eliminates the upgrade ceiling this package would impose.