Filament Iban Laravel Package

Getting Started

Install the package with Composer using the name from the README, then confirm your app meets its Laravel/Filament requirements. Start with the README and the new art/ screenshots to see the intended UI, then run the workbench demo (DemoSeeder, Acme Supply data) if you want a reproducible local example. Your first use case is a Filament form field: add IbanInput::make('iban') to a resource form. For a field named iban, it now defaults to the label “IBAN” instead of Filament’s usual “Iban”.

Implementation Patterns

• Basic form integration: use IbanInput::make('iban') in Filament resource forms, relation forms, or action modals.
• Label override: use ->label('Bank account') when the UI label should differ, while leaving validation messages to the acronym-aware default.
• Validation attribute control: use ->validationAttribute('IBAN') when you need explicit control over the attribute name in validation messages; it wins over the package default and Filament’s label transformation.
• Acronym-safe validation: rely on the v1.0.2 behavior that keeps “IBAN” as written in validation messages (“The IBAN must…”), even though Filament still applies lcfirst to other labels.
• Demo-driven workflow: use the workbench DemoSeeder with Acme Supply data to reproduce screenshots, test field behavior, and validate label/validation-message changes before applying them in your app.

Gotchas and Tips

• Filament’s lcfirst behavior can turn acronym labels into awkward casing such as “iBAN”; v1.0.2 fixes this specifically for IbanInput validation messages, but custom fields may still need ->validationAttribute().
• The default “IBAN” label applies to a field named iban. If your field has another name, set ->label('IBAN') explicitly if you want the acronym in the UI.
• An explicit ->validationAttribute() always wins, so use it when you need precise validation-message wording or when overriding package defaults.
• When debugging label or validation-message issues, check both the field name and any explicit label()/validationAttribute() calls; the workbench demo is the fastest way to compare expected vs. actual output.
• No breaking changes are indicated in v1.0.2. The release is primarily documentation/demo improvements plus a targeted acronym-label fix.