Autogenerated Messages Laravel Package

Getting Started

setnemo/autogenerated-messages generates human-readable validation messages from your Laravel validation rules, so you don't hand-write every 'email.required' => '...' entry.

Minimal setup:

composer require setnemo/autogenerated-messages

The package is discovery-friendly; no service provider registration is normally required. First use case is a Form Request:

use Setnemo\AutogeneratedMessages\...; // check the package README for the exact trait/helper name

class StoreUserRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'email'   => ['required', 'email'],
            'password'=> ['required', 'min:8', 'confirmed'],
            'confirm' => ['same:password'],
        ];
    }

    public function messages(): array
    {
        return autogenerated_messages($this->rules()); // verify exact helper signature in README
    }
}

Where to look first:

1. The package README for the exact helper/trait name and config publish tag (vendor:publish --tag=...).
2. The config/ file if published — that's where message templates and locale fallbacks live.
3. The source's rule-message map, which is what v2.4.0 just extended with same.

Since v2.4.0 is purely additive (a new same rule message), it's safe to upgrade; no migration steps.

Implementation Patterns

• Per-request generation: call the helper inside messages() and return its output. This keeps messages in sync as rules() evolve — the main selling point over static arrays.

• Base Form Request: wrap the helper in an abstract BaseFormRequest so every request inherits autogenerated messages without repeating the boilerplate.

• Override selectively: merge the autogenerated array with a small hand-written array so you keep auto messages but can override specific keys (e.g. brand-voice copy on email.required):

  return array_merge(
      autogenerated_messages($this->rules()),
      ['email.required' => 'We need your email to reach you.']
  );
  

• New in v2.4.0 — same rule: 'confirm' => ['same:password'] now produces a sensible message out of the box (previously it would fall through to a generic or missing key). Update any tests asserting the old fallback text.

• Localization: if the package supports translation keys, keep the generated messages as keys and supply lang/{locale}/validation.php translations rather than hardcoding English.

• CI guard: add a small test that instantiates each Form Request and asserts every rule has a corresponding message key — this catches gaps like the one v2.4.0 closed.

Gotchas and Tips

• Rule-string parsing: autogenerated messages depend on parsing rule strings. Rules passed as rule objects (new Rules\Password()), closures, or arrays with parameters in edge formats may not map cleanly. Prefer string rules when relying on generation.
• confirmed vs same: confirmed implies a _confirmation field, while same:field names the field explicitly. v2.4.0's addition covers the latter; if you previously worked around it with a manual message, remove the override and let the new default apply (or keep it deliberately).
• Wildcards: nested array rules (items.*.email) need matching wildcard message keys. Confirm the generated keys use * appropriately, otherwise Laravel won't bind them.
• Order and merge semantics: array_merge overrides by key, so a generated key of password.confirmed will be replaced by your custom one — good, but watch for cases where the package emits multiple keys per rule and you only override one.
• Locale at generation time: if messages are generated as translated strings rather than keys, generating them during a request pins the locale. Generate keys and translate at render time if you support multiple locales.
• Debugging missing messages: when a rule produces no message, check the rule name against the package's internal map first (that's the extension point for unsupported rules), then check your config cache (php artisan config:clear) if you published config.
• Extension points: if a rule isn't supported, most such packages expose a config map or a registration method to add message templates. Use it rather than scattering manual messages() entries — keeps future rule additions like v2.4.0 consistent.