Scdatetimepicker Bundle Laravel Package

Technical Evaluation

Release scope — patch only, no architectural change. v4.0.2 contains two Dependabot bumps (symfony/http-foundation 7.1.6 → 7.1.7, twig/twig 3.14.0 → 3.14.1) and one third-party view fix (PR #13). No new features, no breaking changes, no deprecations, no API surface change. Nothing in this release alters the integration calculus for a Laravel application: it remains a Symfony bundle targeting a kernel/Twig/DI runtime that Laravel does not provide. The prior recommendation stands unchanged.

What the release does tell us (and it is modestly useful).

• Dependency hygiene exists. Dependabot is enabled and merging. That answers part of key question 3 by inference: the package is being kept current against Symfony 7.1.x and Twig 3.14.x, so it is not abandoned at the framework level. This is a genuine, if small, positive.
• A second contributor exists. PR #13 is from @joesenova, a non-maintainer. Bus factor moves from "one person" to "one person plus occasional drive-by fixes" — still thin, but no longer single-point in the strictest sense.
• The dependency footprint is now partially confirmed: jQuery. The fix is described as a "jquery_layout view fix." That is consistent with the bundle's view layer extending or overriding a jQuery-based layout partial, not merely shipping an isolated widget template. For a Laravel port this matters twice: jQuery is no longer in Laravel's default JS scaffold (removed in Laravel 5.7), and an invasive base-layout override is a larger extraction surface than a single form theme.
• Release process is sloppy. The v4.0.2 notes duplicate the v4.0.1 body, and the "Full Changelog" link in the v4.0.2 block points at v4.0.0...v4.0.1. Minor on its own; relevant only as a signal about how carefully the project is run.

Architecture fit — still a fundamental mismatch. Unchanged from the prior assessment. mwsimple/scdatetimepicker-bundle registers via a Bundle subclass, loads config through a DependencyInjection extension, renders through Twig form themes, and publishes web assets via assets:install. Laravel has no kernel-bundle registry, no Twig renderer, and no DI extension pipeline. Nothing implements Illuminate contracts, so there is no auto-discovery path and no service provider that can resolve it without reimplementing what the bundle already assumes.

What is actually reusable — slightly narrower than first assessed. The payload is a form widget template, a base layout partial (per the jQuery layout fix), and a pinned Bootstrap DateTimePicker JS/CSS set. The layout coupling means extraction is not a clean single-file lift; expect to read two templates and discard the inheritance chain. Still portable, still not installable.

Integration feasibility — low, cheap exit, unchanged. Do not composer require this into a Laravel app. Read the templates as reference, rebuild as a Blade component, and pull the picker from npm via Vite. 1–2 days for a single form; 3–5 days for a validated, repopulating, localized, timezone-aware reusable component.

Technical risk — still concentrated in the supply chain, not the code.

• ~11 stars, 0 dependents, one maintainer: no ecosystem validation.
• Active but thin maintenance: Dependabot bumps plus occasional community PRs. Version-bump releases are activity, not assurance.
• The larger risk remains the wrapped client library. The Eonasdan Bootstrap DateTimePicker lineage is end-of-life upstream in favour of Tempus Dominus; inheriting a deprecated picker for a new build is a poor trade regardless of how well the PHP wrapper is maintained.
• Unverified and not resolved by this release: PHP/Symfony constraint matrix beyond the two bumped packages, Bootstrap 3/4/5 support, i18n coverage, test coverage, CI matrix.

Key questions — updated.

1. Which Symfony and PHP versions are declared? Partially answered: tracks Symfony 7.1.x / Twig 3.14.x. PHP floor and CI matrix still unconfirmed.
2. Which underlying JS picker and version does the bundle pin, and is that version still receiving upstream fixes? (Unchanged — highest-value open question.)
3. Is the "jquery_layout" a base-layout override that downstream apps inherit? If so, how much of the host view layer does the bundle assume it owns?
4. Does the form type provide server-side validation, or is validation entirely the host app's responsibility?
5. Is there any test coverage behind the v4.0.2 view fix, or was it shipped without a regression test?
6. Does the maintainer respond to issues, and what is the historical issue-close rate?

Integration Approach

Stack fit — adopt the pattern, not the package. Unchanged. The repository is a design reference: a Blade component for markup, @vite for delivery, FormRequest for validation, old() for repopulation, Carbon for formatting.

Migration path (bundle approach → Laravel-native), revised for the layout coupling:

• Twig form theme + jQuery layout partial → anonymous Blade component (<x-datetime-picker>), self-contained, no layout override. Props: name, value, format, min, max, locale, timezone.
• Symfony asset publication → npm dependency through Vite; no manual copy into public/.
• Symfony form type options → FormRequest rules plus component props; validation stays server-side and authoritative.
• Twig translation domain → Laravel lang/ files keyed to component labels and error text.
• jQuery → do not carry it over. The component should be a single vanilla-JS or picker-library initializer; introducing jQuery into a Vite build for one field is not justified.

Compatibility notes that bite in practice:

• Timezone. Client pickers emit local strings; date validation and Carbon casting expect a defined input timezone. Decide up front whether the component emits local time or UTC ISO-8601 and enforce it in a cast or mutator.
• Old input. old() returns the raw submitted string; the picker's display format must match, or the field silently blanks on validation failure. Most common defect in ported picker components.
• Validation format. date_format:Y-m-d H:i must match the picker format exactly, including whether seconds are emitted.
• CSRF and Livewire/Inertia. Use a Blade partial or a JS island respectively; do not attempt to reuse Twig partials in either.
• jQuery coexistence. If the host app still loads jQuery for legacy reasons, verify the picker library does not double-bind or conflict on $ before wiring initialization.

Sequencing.

1. Spike (0.5–1 day): read both the widget template and the jQuery layout partial; identify the pinned JS library and version; confirm upstream maintenance status.
2. Decision gate: if the underlying JS is the deprecated Eonasdan picker, build on a maintained alternative (Tempus Dominus, Flatpickr, or native <input type="datetime-local">) rather than porting a dead dependency.
3. Build (1–3 days): Blade component, Vite entry, FormRequest rules, timezone contract.
4. Harden (1 day): old-input repopulation tests, DST and timezone boundary cases, locale rendering, mobile/accessibility pass.
5. Document: one page in the internal component library so the next team does not rediscover this repository.

Operational Impact

Maintenance. Ownership transfers entirely to your team on fork or port. The fork surface is small — two templates and one JS binding — and the alternative is onboarding a single-maintainer Symfony bundle into a non-Symfony runtime. Ongoing cost: a few hours per quarter tracking the underlying JS library's releases and advisories. Note that the upstream project's own maintenance is now largely automated dependency bumps; do not mistake Dependabot activity for a support commitment.

Support. No vendor, no SLA, no meaningful community. Issue triage is one person's attention, supplemented by occasional community PRs. For a component that touches every date entry in an application, that is not a supportable posture for a production dependency.

Scaling. Effectively zero server-side impact; the picker is client-side. Real considerations are asset weight (picker plus locale files can add tens of KB — load locales lazily) and form density (many pickers per page multiply initialization cost). Solved by bundling through Vite with per-locale code splitting rather than shipping every locale.

Failure modes to plan for.

• Timezone drift between browser locale, submitted value, and application timezone — surfaces as off-by-hours records after DST transitions.
• Silent blanking on validation failure from a format mismatch between old() and the picker's display format.
• Asset path breakage if manual copies into public/ creep in alongside Vite's manifest.
• Upstream abandonment of the wrapped JS library, leaving an unpatched client dependency.
• Locale mismatch — month/day names rendered by the JS library will not follow app.locale unless explicitly wired.
• Layout override bleed if anyone attempts a partial port of the bundle's jQuery layout into a Blade layout, silently changing styling or script order for unrelated views.

Ramp-up. Low for a Laravel developer — the ported component is idiomatic Blade and Vite. Medium only if someone insists on installing the bundle and reverse-engineering Symfony DI inside Laravel, which is the path to avoid. Budget half a day of onboarding for the timezone and format contracts; those are the non-obvious parts.

Bottom line. v4.0.2 is a routine patch release — two dependency bumps and a view fix — and does not change the verdict. It adds two small positive signals (Dependabot hygiene, a second contributor) and one clarifying negative (a jQuery base-layout dependency, meaning the reusable surface is wider and more legacy-bound than a single template). The package remains a low-signal dependency and is architecturally foreign to Laravel. Its only durable value is as a reference for markup. Recommend: do not adopt; extract and rebuild natively, and prefer a maintained picker over the one this bundle wraps.