Dictionary Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on shared "static choice" primitives. Gender, civility/salutation, title, marital status, and similar closed value sets get retyped into every form, entity, and migration. This package is a candidate to vendor rather than build an internal enum/choices module — the scope is small, the license is MIT, and the cost of replacing it later is low.
• Roadmap: boilerplate reduction in CRUD/admin surfaces. Every new app scaffold we ship contains the same 5–10 hardcoded arrays. Standardizing on one source of truth shortens time-to-first-form and shrinks the review surface for "did you spell 'Mrs' the same way as last time?" defects.
• Consistency and analytics governance. Canonical stored values (not display labels) matter for reporting: a CRM that stores M, Mr, Mister, and mr in the same column is a data-quality problem. A dictionary package forces the conversation about codes vs. labels early, which is exactly when it is cheapest.
• Localization strategy. Label sets for these fields are inherently locale-dependent. Adopting a dictionary makes i18n of choice labels an explicit, owned concern instead of a per-developer afterthought.
• Feature-level use cases where this pays off fastest: registration and profile forms, HR/people directories, KYC and identity fields, healthcare intake, civic/government forms, and any multi-tenant product where each tenant expects "standard" field options.
• Not a strategic platform decision. This does not touch auth, billing, data plane, or compliance. It is a leaf dependency; treat it as a tactical utility, not an architecture commitment.

When to Consider This Package

Consider it when:

• The stack is Symfony, and the bundle's supported Symfony/PHP version constraints match your runtime. (See the caveat below — this is a Symfony bundle, not a Laravel package, despite the framing.)
• You have three or more apps or modules duplicating the same literal option arrays, and the duplication is already causing drift bugs.
• You want a small, forkable, MIT-licensed dependency whose entire value can be reproduced in an afternoon if the maintainer walks away.
• You need standard choice sets today and are willing to accept unvetted maturity in exchange for a head start.
• You can absorb the package behind our own thin interface (a ChoiceProvider / enum factory we own), so call sites never depend on the vendor namespace directly.

Look elsewhere — or build internally — when:

• Framework mismatch is unresolved. The package is a Symfony bundle; a Laravel or framework-agnostic codebase gets little value from the bundle wiring and would only be using it as a data file. In that case, extract the arrays into our own config and drop the dependency.
• You need authoritative, deep reference data. Countries, subdivisions, currencies, languages, and phone formats need symfony/intl, CLDR/ISO-maintained datasets, or a dedicated library — not a hand-curated list. Static "civility" lists are fine; regulatory or geo data is not.
• You need validation, not just options. If the requirement is "reject invalid values at the boundary," you want enums with validation and DB constraints, which you should own.
• Procurement or compliance requires provenance. Zero stars, zero dependents, and a single maintainer mean no community backstop, no security response process, and no CVE history to inspect. Any product in a regulated or high-availability tier should not take this on without an internal fork.
• You need SLAs, support, or a deprecation policy. None exist here.
• The team already has an enum convention (PHP 8.1 backed enums plus a shared Support\Choices namespace). Adding a dependency then creates two idioms for one problem.

Adoption gate before any production use: confirm the framework/version constraint file, check whether labels are translatable and in which locales, confirm whether the API returns scalars or enums, and verify test coverage. If any of those are unclear, vendor the data and skip the package.

How to Pitch It (Stakeholders)

To executives: This is a small MIT-licensed utility that centralizes the fixed option lists — gender, civility, and similar — that our teams currently retype in every application. The business value is modest but real: fewer copy-paste defects, consistent values in reporting, and faster setup of new forms. The risk is also modest because it is small: if the project stalls, we can copy the data into our own codebase in a day. Recommendation: approve a short, time-boxed spike and use it behind an internal wrapper — do not treat it as a strategic or long-term dependency, and do not adopt it in regulated surfaces without an internal fork.

To engineering: Adopt it as a data source, not an interface. Wrap it in a Choices / ChoiceProvider abstraction we own, so call sites stay vendor-independent and a future swap is a one-file change. Before merging: pin the version, verify Symfony/PHP constraints against our matrix, confirm translation coverage for our locales, and check that it returns stable machine codes rather than display strings. If any of that fails, lift the arrays into our own config — the package's entire value is reproducible, so there is no lock-in either way. Flag for the team that this is a Symfony bundle with a single maintainer and no dependents; treat it as unvetted third-party code and review it as such.