Reform Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (form-data mapping): Informs whether to adopt a third-party abstraction for decoupling Symfony Form data from domain entities/DTOs, or write the mapper in-house (~1–3 days of engineering for a focused implementation). The 0.2.0 release does not change this calculus — it ships a presentational Twig template, not mapping capability. The honest output remains "build or vendor," not "buy."
• Framework/platform scope decision: The package is a Symfony bundle, not a Laravel package — it registers services and config through the Symfony kernel and has no Laravel service provider, facade, or config publishing. The new artifact (reform_bootstrap_4_layout.html.twig) is a Symfony/Twig form theme, which reinforces rather than relaxes the Symfony-only framing. Any roadmap item assuming a Laravel integration must be re-scoped or dropped.
• Legacy maintenance budgeting: For teams already running it, this feeds the decision to (a) freeze the dependency, (b) fork and vendor it internally under MIT, or (c) budget a migration sprint. Release 0.2.0 ends the "no release since 2018-07-09" characterization, but a single added template file is not evidence of a restored release cadence; the runtime gap against current PHP baselines is unchanged and still requires compatibility work on any fork.
• Dependency governance / vendor-risk scoring: A concrete data point for a "no unmaintained dependencies in new services" policy: zero stars, zero dependents, no security response path, no documented support commitment. Treat repo archival status as to be re-verified — a published release implies some write access — but one cosmetic contribution does not constitute a maintained dependency.
• Use-case fit assessment: Relevant only where the requirement is genuinely "map submitted form data into a separate object graph with transformation rules." 0.2.0 extends only the presentation layer (Bootstrap 4 form layout); it adds no validation, hydration, or mapping capability. If the requirement is plain validation, request parsing, or CRUD scaffolding, this still adds a concept without adding capability.
• Upgrade/breaking-change exposure: 0.2.0 is additive — a new template with no API, config, or service-definition changes and no deprecations. There is no forced action for existing consumers and no reason to accelerate or defer an upgrade on compatibility grounds.
• Reference-design input: Even as a non-adoption, the source is MIT-licensed and small — it can seed an internal design doc for a mapper without creating a runtime dependency. The new template is likewise reusable as a standalone form theme if we ever need Bootstrap 4 form markup, independent of adopting the bundle.

When to Consider This Package

Consider it only when all of these are true:

• You maintain an existing Symfony application that already depends on it and the cost of removal now exceeds the cost of freezing it.
• You are willing to fork it into your own namespace and own the maintenance, including PHP-version compatibility patches.
• The functionality is peripheral — form plumbing, not payments, auth, or anything with a security surface.
• Your team has a written exit criterion and a target date for removal.

Look elsewhere — or build — when any of these are true:

• Greenfield project, or any project expected to live more than ~12 months.
• Laravel or framework-agnostic PHP. This is not the package for that; the naming and the "Laravel/PHP package" framing in most catalogs is misleading.
• You need a support contract, security advisories, or a responsive maintainer. The 0.2.0 release does not establish any of these: zero dependents, no published support policy, no advisory history to point to.
• You need modern PHP compatibility guarantees, static analysis at current levels, or PSR-compliant modern interfaces.
• The actual need is validation or DTO hydration — use the framework's native options, or a maintained serializer/mapper.
• You only want Bootstrap 4 form markup. Copy the template and depend on nothing.

Default position: do not adopt. The signal set (0 stars, 0 dependents, years of dormancy, a single template-only release) is not a "small but stable" profile — it is a dormant profile with one incidental commit and no evidence of production use in the wild. The 0.2.0 release is a reason to re-check the repository's status, not a reason to change the recommendation.

How to Pitch It (Stakeholders)

To executives (one paragraph): We re-evaluated ruwork/reform-bundle, a small MIT-licensed Symfony bundle for form-data mapping, following its 0.2.0 release. The release adds a single Bootstrap 4 form-layout template — no functional, security, or compatibility changes — and the repository still shows no measurable adoption and no support commitment. Recommendation is unchanged: do not adopt. Note for accuracy that the package is no longer strictly "unreleased since 2018," so our dependency register should reflect an active-but-dormant status rather than a frozen one; if it is already in our stack, fund a scoped removal rather than a renewal.

To engineering leadership:

• Risk is concentrated in abandonment, not in code quality — the library is small and readable, which is exactly what makes forking cheap and also what makes depending on it unnecessary. A one-file release does not shift that balance.
• 0.2.0 is additive and non-breaking: no API, config, service-definition changes, no deprecations. Nothing in existing consumers breaks, and no upgrade work is triggered.
• Two viable paths remain: (1) Vendor-and-own — fork under MIT, pin to our PHP baseline, add tests, accept ~2–4 days/year of upkeep. Justified only if removal is genuinely expensive. (2) Replace — reimplement the mapping logic internally or move to a maintained alternative; typically 1–2 sprints for a mid-sized form surface.
• Correct the platform assumption early: this is a Symfony bundle and does not serve Laravel consumers. Any ticket written against "our Laravel package" needs rewriting before estimation.
• If the only appeal of 0.2.0 is the Bootstrap 4 form theme, vendor the single Twig file — that satisfies the need with zero dependency and zero vendor risk.

Ask: Approve the non-adoption decision, and authorize a spike to size the removal effort for any service currently depending on it. Success measure: zero production services resolving this bundle within two quarters, with no regression in form-handling behavior.