Extended Form Type Laravel Package

Product Decisions This Supports

• Build-vs-buy on form plumbing. This bundle is best read as a reference implementation, not a dependency. The decision it informs is "do we adopt, fork, or reimplement the pattern in-house?" — and for a 0-star, 0-dependent package last released in 2018, the honest answer is almost always "harvest the idea, write ~100 lines ourselves."
• Roadmap scoping for form-heavy surfaces. Relevant if your roadmap includes admin panels, CMS-style content types, tenant-configurable forms, or any feature where form definitions are data rather than code. The package's core premise — reducing boilerplate when passing custom data/options into Symfony form types — maps directly to how much engineering time those features will cost.
• Ecosystem fit check. The package is a Symfony bundle, not Laravel. If the team is on Laravel (even with a forms package bolted on), this closes the evaluation immediately. It is only a candidate in a Symfony 3/4 + PHP 7.x codebase.
• Maintenance liability sizing. Zero stars, zero dependents, no release in seven years, and a 0.06 maturity score are not "early-stage" signals — they are "abandoned" signals. The PM decision is whether the team is willing to own an unmaintained transitive dependency, including security patching and PHP/Symfony version bumps.
• Prioritization signal. If the capability is genuinely needed, the low cost of reimplementation argues for scheduling it as a small internal ticket rather than spending review cycles on adoption, licensing, and fork governance.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is Symfony 3.x/4.x on PHP 7.x (matching the 2018 release window), and an upgrade is not on the near-term roadmap.
• You have a specific, verifiable gap that native configureOptions, FormTypeExtensionInterface, form events, and the data/data_class options do not cover — confirm this with a spike before evaluating third-party code.
• Someone on the team has read the source and can defend it; the bundle is thinly documented and effectively unmaintained, so the code is the documentation.
• You intend to vendor or fork it, with a named owner and a test suite, rather than add it as a live Composer dependency.

Look elsewhere — or write it yourself — when:

• You're on Laravel or any non-Symfony framework. Wrong ecosystem entirely.
• You're on Symfony 5/6/7 or PHP 8.x. The release predates these by years; compatibility is unverified and unlikely without patching.
• Native Symfony form options and type extensions already express your requirement. Most "extended form type" boilerplate complaints from that era were subsequently addressed upstream.
• You need a support contract, CVE response, or upgrade path. None exist here.
• Your team lacks spare capacity to own abandoned code. The true cost of this package is not the license (free) but the permanent maintenance tail.

How to Pitch It (Stakeholders)

For executives: This is not a purchase or a dependency recommendation. It's a piece of abandoned open-source code from 2018 that we evaluated as a design reference for reducing form-building boilerplate. Recommendation: do not add it to the stack. If the underlying pattern is valuable, we replicate the ~100 lines internally, which we control, test, and can upgrade — at a fraction of the long-term risk of owning unmaintained third-party code with zero community and no security response.

For engineering: Treat grossum/extended-form-type as a pattern source only. It's a Symfony bundle (not Laravel), last released 2018-04-13, with no dependents and no maintainer activity — so no upgrade path and no CVE coverage. First, verify whether native configureOptions / FormTypeExtensionInterface / form events already solve the problem; they usually do. If a real gap remains, read the source, extract the approach, and implement it in-house with tests. Do not add it to composer.json.