Polyfill Form Dti Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a Symfony bundle, not a Laravel package. It exists to backport DateTimeImmutable behavior into Symfony Form's DateTimeType on Symfony versions that predate native support (native DateTimeImmutableType/input handling landed in Symfony 4.3, May 2019). Laravel does not boot Symfony bundles; it consumes selected Symfony components but not the FrameworkBundle/kernel, and it has no Symfony Form layer by default. For a Laravel codebase the problem it solves does not exist in the same shape — immutable date handling is achieved with Eloquent casts (datetime:immutable, immutable_datetime), Carbon/CarbonImmutable, and DTO boundary types.

Integration feasibility. Low. Making it work under Laravel would mean installing symfony/form, registering the bundle's extension manually or booting a minimal Symfony kernel, and wiring form types — significant plumbing for a behavior that is now native upstream. Composer constraints are the harder blocker: a 2018 bundle almost certainly pins PHP 7.x and Symfony <4.3, which conflicts with Laravel 9+ (PHP 8.1+, Symfony 6/7 components). Feasibility is effectively "no" without forking.

Technical risk. High. It is archived, has 1 star, 0 dependents, and its last release was 2018-02-11. There is no security process, no maintainer, and no CVE visibility. The functionality is obsolete relative to modern Symfony, so the package's only value is in a frozen legacy Symfony ≤4.2 application. The adoption score of 0.0025 accurately reflects ecosystem reality; the opportunity score of 7.22 is a scoring artifact, not a signal of latent demand for Laravel teams.

Key questions.

• Is there any actual Symfony Form usage anywhere in the estate, or is this a Laravel-only shop?
• Which PHP/Symfony versions are in play, and does a legacy Symfony ≤4.2 service still need the polyfill?
• Is DateTimeImmutable already enforced at domain boundaries via casts, DTOs, or value objects?
• Could a ~20-line custom form type extension or an Eloquent cast replace this entirely?
• If a legacy consumer exists, what is the sunset date for that service?

Integration Approach

Stack fit. None for Laravel. Acceptable only inside a legacy Symfony application pending upgrade. The idiomatic Laravel equivalent is a combination of immutable Eloquent casts, CarbonImmutable, typed DTOs, and validation rules — not a third-party bundle.

Migration path.

1. Inventory any DateTimeType usage and any code relying on mutable DateTime returns.
2. Replace with native DateTimeImmutableType (Symfony 4.3+) or a small local form type extension if pinned below that.
3. In Laravel, convert model attributes to immutable_datetime casts and enforce DateTimeImmutable at request/DTO/repository boundaries.
4. Delete the polyfill rather than port it.

Compatibility. Expect php ^7.x and symfony/form <4.3 constraints. That is incompatible with current Laravel (10/11/12) and modern Symfony components. Do not attempt to install it alongside a modern Laravel application; dependency resolution will either fail or force downgrades across the tree.

Sequencing. Do not place this on a Laravel roadmap. If a legacy Symfony service is identified, sequence removal into the next Symfony minor/major upgrade and use the polyfill only as a temporary bridge behind a feature flag. If it must be retained briefly, vendor/fork it with a pinned commit and a documented removal ticket.

Operational Impact

Maintenance. Zero upstream. Archived since 2018 with a single star and no dependents means any use becomes internal ownership. The code surface is small (likely one bundle class plus a form type extension), so a fork is cheap — but it is frozen code to be carried, not a dependency to be trusted.

Support. No community, no issue triage, no security advisories. On-call support becomes entirely internal, and knowledge of the polyfill's behavior will decay quickly as the team turns over.

Scaling. Runtime scaling is irrelevant; the risk is build and upgrade scaling. A pinned legacy bundle becomes a persistent blocker to PHP and framework upgrades, and can hold back security patches in unrelated packages through Composer conflict resolution.

Failure modes.

• Composer install/update conflicts against PHP 8 and Symfony 6/7.
• PHP 8 deprecations or fatals in unmaintained 2018-era code.
• Silent behavioral divergence from native DateTimeImmutableType (mutation vs. immutability, timezone handling, input formats).
• Type mismatches at persistence boundaries where a DateTime is expected but an immutable instance arrives, or vice versa.
• Lockfile pinning that blocks CVE remediation elsewhere in the estate.

Ramp-up. Reading the package is trivial — it is small. But ramp-up for a Laravel team is negative ROI: the useful investment is a short internal standard on immutable date handling (casts, DTOs, CarbonImmutable), which is a few hours of guidance and code review. Adopting the bundle would add onboarding cost for zero functional gain.