Gender Laravel Package

Getting Started

• Install with Composer, then publish the package config and any views/translations using the package’s documented vendor:publish tags. The first place to look is the published config file: v1.1.0 adds an optional extended gender set, so confirm the flag/key that controls which option set is active.
• Keep the default behavior unless the product explicitly needs the extended set. The release is additive and opt-in, so existing forms, validation, and stored data should continue to work unchanged.
• First use case: replace a hardcoded gender dropdown in a profile/settings form. Use the package-provided options for the <select> and the package validation rule in the form request, then store the selected value in a normal string column.
• Smoke-test both modes early: with the extended set disabled, confirm the previous option list and validation still behave as before; with it enabled, confirm the form renders the additional options and validation accepts them.

Implementation Patterns

• Treat the package’s option list as the single source of truth. Do not duplicate gender values in Blade templates, form requests, factories, or API resources; resolve them from the package/config so enabling the extended set updates every surface consistently.
• In form requests, use the package’s validation rule where possible. If only some forms should allow the extended set, build a context-specific Rule::in(...) from the package’s active options rather than hardcoding a second list.
• In Blade, iterate the package options as value/label pairs, preserve old() input on validation failure, and render labels separately from stored values. This keeps storage stable if labels are later translated or reordered.
• If the package exposes an enum, value object, or cast, use it for model attributes and comparisons. Otherwise add a small accessor for the display label and keep the raw stored value canonical.
• For APIs, return a stable machine value plus a display label. Document that v1.1.0 may add new values when the extended set is enabled; version the endpoint or gate the expanded set behind a feature flag if mobile/third-party clients assume a fixed list.
• For admin filters and reporting, group by stored canonical values and avoid binary assumptions. Provide an “unknown/not specified” bucket for legacy rows and consider whether extended values should be reported individually or rolled up for existing dashboards.
• In multi-tenant apps, make the extended-set flag tenant-aware if possible. Otherwise keep it application-wide and document the behavior so one tenant’s product decision does not silently change another’s validation surface.
• Add tests for both configurations. Use a data provider or separate test cases for extended set enabled/disabled, and add factory states for extended values so feature tests cover realistic profile data.
• Before enabling the extended set in production, widen the storage column if necessary. Use a string/text column sized for long Facebook-derived labels rather than a narrow enum or varchar(20).

Gotchas and Tips

• The extended set is opt-in: enabling it changes the accepted validation surface and the UI options. Do not flip it globally without product, legal, and analytics review; keep the default unchanged for existing applications.
• Facebook-derived gender labels can be long. Check database column length, index sizes, CSV/Excel exports, table filters, and mobile layouts before rollout. Avoid database enum columns entirely for this data.
• Keep config cache in mind. After toggling the option set, run php artisan config:clear (and restart queue workers) so web, API, and queued jobs all validate against the same list. In tests, set config explicitly per test and clear it afterward.
• Ensure validation and UI stay in sync. A common failure is rendering the extended list in the form while the backend still validates against the legacy list, or vice versa when the config differs between environments.
• Existing rows remain valid, but if you previously maintained a custom gender list, compare it to the package list before switching. Map legacy custom values to canonical package values or keep them accepted through a transitional rule.
• Labels may be English-first because the set is based on Facebook’s options. Translate display labels if needed, but keep stored canonical values stable so reporting and API contracts do not break.
• Gender data is sensitive personal data. Minimize collection, restrict access, avoid logging raw values, and update privacy notices if the expanded set changes what is collected.
• Do not conflate an extended predefined list with a free-text “self-describe” field. If the product needs self-description, add a separate optional field and decide how it interacts with validation and reporting.
• Use the package’s extension points—published config, views, translations, and custom validation rules—rather than forking the package. That keeps future option-set updates and bug fixes easier to adopt.