Polyfill Form Dti Bundle Laravel Package

Product Decisions This Supports

• Legacy platform triage. This bundle is a symptom, not a solution: it exists because Symfony Forms lacked native DateTimeImmutable support in the DateTimeType before Symfony 3.1. Finding it in a composer.json tells you an application is pinned to an unsupported Symfony line (roughly 2.x–3.0 era) — a direct input to "upgrade vs. freeze vs. sunset" roadmap decisions.
• Build vs. buy — answered as "neither." In its era, this was a legitimate buy: a tiny MIT-licensed shim instead of hand-rolling a custom form type. Today the correct decision is "delete," because modern Symfony handles immutable date/time natively. There is no build effort and no buy cost.
• Technology radar placement. With 1 star, 0 dependents, an archived repo, and a last release in February 2018, this belongs in the "Hold / Retire" ring. It should not appear in any new architecture, template, or starter kit.
• Feature scope on legacy backlogs. If the product still runs a pre-3.1 Symfony app, immutable date handling in forms is a real (small) capability gap this package closes — worth including only as a stopgap line item on an upgrade epic, never as a standalone initiative.
• Risk register entry. An archived dependency with no maintainer is an unpatchable surface. It is low-severity (narrow scope, MIT), but it is a leading indicator of a broader unsupported-stack problem worth budgeting for.
• Not a Laravel decision. Despite the "Laravel/PHP package" framing, this is a Symfony bundle with no Laravel applicability; Laravel teams should treat it as out of scope and use Carbon/Illuminate validation for immutable date handling.

When to Consider This Package

Consider it only if all of the following are true:

• The application is on a Symfony version whose DateTimeType cannot produce DateTimeImmutable (pre-3.1, e.g., 2.7/2.8/3.0).
• The domain model genuinely requires immutability (value objects, event sourcing, audit-heavy date fields) and swapping to mutable DateTime is not acceptable.
• A Symfony upgrade is blocked for a defined period, and a temporary, disposable shim is preferable to a bespoke form type.
• You accept that the dependency is archived: no security fixes, no PHP 8+ compatibility guarantees, no maintainer support.

Look elsewhere (i.e., do not adopt) if:

• You are on Symfony 3.1+ (including 4.x, 5.x, 6.x, 7.x). Native support exists; adding this is pure liability.
• You are on Laravel or any non-Symfony PHP framework — this bundle is not applicable.
• You are starting anything new. A modern stack makes this package meaningless.
• You need maintained dependencies, a support contract, or a security-response path — the archived status, single-digit stars, and zero dependents rule it out.
• You are willing to invest a few hours: writing an equivalent custom form type is small, self-owned, and easier to remove than a third-party bundle.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a tiny compatibility shim from the Symfony 2.x/3.0 era that let forms accept immutable date values before the framework did so natively. It has been archived since 2018, has essentially no user base, and is superseded by core Symfony functionality. It is not a strategic dependency and should not be adopted anywhere; its only value to us is as a diagnostic signal that an application carrying it is running an unsupported framework version. Recommendation: no new investment, remove on sight, and use its presence to justify upgrade budget.

To engineering leadership: Treat it as technical-debt telemetry. Where it appears, the real work item is the Symfony upgrade — after which removal is a one-line composer remove with no migration cost, since the native DateTimeType is a drop-in replacement for the polyfilled behavior. Do not fork it, patch it, or wrap it; the code surface is small enough that a first-party form type is cheaper to own than an unmaintained bundle.

To the engineering team: If you encounter it, do not modernize it — delete it. Verify the Symfony version, confirm the native immutable support path, and add a regression test around the affected form fields before removal.