Form Kit Bundle Laravel Package

Product Decisions This Supports

• Feature scope: form-heavy, multi-locale surfaces. Any roadmap item that ships lots of Symfony forms (admin back-office, onboarding wizards, CRUD panels, B2B self-service portals) benefits from moving label/placeholder/help text out of per-field PHP options and into a convention (form_snake.field_snake.label). This shortens the definition-of-done for each new screen.
• Roadmap: i18n/l10n debt reduction. If "full localization coverage across all forms" is a recurring roadmap line, convention-based keys convert an open-ended audit into a mechanical, testable convention. That is a roadmap-level lever, not just a code refactor.
• Build vs buy: the alternative is an in-house option resolver / form-extension trait. This bundle is a narrow, MIT-licensed, ~single-responsibility component covering translation keys plus cascading option merge (global → field type → form → field) and YAML-driven named configs. Buy (adopt) if the pattern matches; build only if you already have a design-system/theme layer that owns this.
• Use cases it unlocks cheaply:
  • Multiple named form configs in one app (e.g. public, admin, partner) without duplicating option arrays.
  • Per-field-type defaults so new text/email/choice fields get sane placeholders and help text with zero per-field code.
  • Centralised copy ownership — content/marketing can change placeholders without touching PHP, which is a workflow decision (who owns copy) as much as a technical one.
• Delivery-efficiency metric to baseline before adoption: average dev-minutes per form field and number of i18n copy defects per release. Both are measurable and directly attributable, which makes the adoption decision falsifiable.
• Portfolio signal: high opportunity score but very low adoption score (0 stars, 0 dependents) means "under-adopted niche tool," not "emerging standard." Treat this as a tactical dependency, not a strategic platform bet.

When to Consider This Package

Consider it when all of the following hold:

• Stack fit: the product is Symfony (7.4 / 8.0 / 8.1) on PHP ≥ 8.2. Note this is a Symfony bundle — it is not usable in Laravel, so any Laravel roadmap item is out of scope regardless of the "PHP package" framing.
• Form density: the domain has a meaningful number of forms (rule of thumb: 15+ fields across 5+ forms, or growing). Below that, the YAML indirection costs more than it saves.
• Localisation is real and multi-locale: at least two locales, with copy churn expected. Single-locale products get no value from the key convention.
• You want configuration over code: the team is comfortable that form copy and defaults live in YAML, reviewed as config, rather than in PHP form classes.
• You have a bounded blast radius: you can wrap adoption behind your own form-type base class or a thin adapter, so the dependency is swappable.

Look elsewhere when any of the following hold:

• Maturity risk is unacceptable. 0 stars, 0 dependents, and a single-maintainer profile (inferred from repo conventions) means abandonment and key-person risk are real. For a revenue-critical, long-lived surface, prefer an in-house resolver you own.
• You need a production track record. There is no ecosystem signal here — no downstream consumers to inherit bug reports from. Do not put this on a critical path without a spike first.
• Your forms are predominantly front-end driven (LiveComponents, Inertia, React/Vue islands). The bundle governs server-rendered Symfony form options; it does not help with client-side validation UX or design-system tokens.
• You already own a design system / UI kit that centralises labels, hints, and placeholders. Two competing sources of truth is worse than either alone.
• You need dynamic or per-tenant runtime configuration. The design is YAML-config driven, which implies deploy-time configuration; if tenants must edit their own copy at runtime, you need a database-backed layer on top.
• Your bottleneck is form rendering/theming, not form option boilerplate. This bundle reduces repetition in options; it is not a theme/template system.
• Trivial forms or a one-off internal tool — dependency overhead exceeds the payoff.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, MIT-licensed Symfony add-on that removes repetitive per-field form configuration — labels, placeholders, help text, defaults — by turning them into a naming convention and a config file. The business case is velocity and localisation quality: new forms ship faster, and translation copy stops being scattered across PHP. Cost is near zero (free licence, small integration surface). The main risk is maturity — the project has essentially no adoption yet — so the recommendation is a one-sprint, two-form pilot, not a broad rollout. If the pilot does not measurably cut per-field effort, we drop it at negligible cost.

For engineering leads:

• What it does: convention-based translation keys, configurable defaults, multiple named configs via YAML, and cascading option merge from global → field type → form → field. That cascade is the actual value: it removes duplication and gives a predictable override order.
• Why it's low-risk to trial: MIT, PHP 8.2+/Symfony 7.4–8.1 aligned, and it targets form-type option resolution — a narrow seam. We can adopt it behind our own abstract form type so no application code references the bundle directly.
• What we must verify in the spike: (1) the cascade order behaves as documented for our field types; (2) Symfony's form theme and our Twig overrides still win where they should; (3) config loading cost and cache warm-up in our deploy pipeline; (4) test-story — we will need our own regression tests around the merge behaviour because we cannot rely on an external suite.
• Exit plan: because it is MIT and narrowly scoped, a fork or a ~200-line in-house replacement remains viable. We are not locking ourselves in.

For product/design stakeholders:

• Copy (labels, placeholders, help text) becomes reviewable as configuration rather than buried in code — which changes who can change it and when, and makes localisation review a checklist instead of an archaeology exercise.
• Expect a short adjustment period where the team agrees key-naming conventions; that convention is the durable asset, and it survives even if we later drop the bundle.

Decision requested: approve a timeboxed spike (one sprint, two representative forms) with a go/no-go gate on measured per-field effort and i18n defect count.