Arabify Laravel Package

Getting Started

Arabify is a Laravel package that exposes an arabify() helper for Arabic-language formatting (numbers, text, or dates depending on the configured driver). v1.3.2 is a small release whose only stated change is where the arabify() function is placed — so the first thing to read is not the feature set but the autoload wiring.

Minimal steps:

1. composer require the package, then immediately run composer dump-autoload. Helper functions are loaded through Composer's files autoload, not PSR-4 class autoloading; a stale autoload map is the single most common cause of "function not found" after upgrading to 1.3.2.
2. Publish and open the config: php artisan vendor:publish --tag=arabify-config. This is the place to confirm locale, driver, and any formatting defaults before you touch code.
3. Open the package's composer.json and read the autoload.files / autoload.psr-4 blocks side by side with the service provider. The release note says the function moved, so this diff tells you whether you are calling a global arabify() or a namespaced one.
4. Verify in php artisan tinker:

   function_exists('arabify');        // global helper present?
   arabify(1234.5);                   // returns expected Arabic output?
   

   If function_exists is false, look for a namespaced variant (App\Support\arabify, Arabify\arabify, etc.) before assuming the package is broken.

First use case: a single call site in a Blade view or formatter class — {{ arabify($invoice->total) }} — proving the helper resolves at runtime before you refactor anything else. Do not roll the helper across the codebase until you have confirmed placement on 1.3.2 in one place.

Implementation Patterns

Isolate the helper behind your own wrapper. Given that placement is explicitly unstable across releases, do not call arabify() directly from dozens of views. Add a thin indirection:

// app/Support/ArabicFormatter.php
final class ArabicFormatter
{
    public static function number(float|int $value): string
    {
        return arabify($value); // single point of contact with the package
    }
}

When 1.3.x moves the function again, you edit one file, not the whole app. This also makes the dependency mockable in tests.

Call sites by context.

• Blade / views: resolve via the wrapper or a Blade directive rather than a bare global, so a namespace change doesn't silently break rendering.
• API resources: format at the resource layer, not in the model, so raw values stay intact for other consumers.
• Queued jobs and console commands: safe — the helper is autoloaded globally, no HTTP/locale bootstrapping required. Confirm app()->getLocale() is what you expect in queue workers, since locale is not inherited from the request that dispatched the job.

Integration tips.

• If you have queued or cached formatted output, a formatting change is a cache-invalidation event; version your cache keys (e.g. invoice:total:ar:v2).
• Prefer calling the package at the presentation boundary so that switching the Arabic driver later is a config change, not a data migration.
• In tests, assert on the wrapper's output once, and use the wrapper as the seam everywhere else — this keeps your suite green through helper-placement churn.

Gotchas and Tips

The release note is the gotcha. "Modify Where The Arabify Function Should Place" is ambiguous: it may mean the helper moved between files inside the package (harmless), or that it is now namespaced / no longer globally registered (breaking). Treat 1.3.2 as a potentially breaking change on the function's FQN until you have proven otherwise with function_exists() and a real call. Pin the version in composer.json if you cannot verify quickly.

Autoload and opcache staleness. After upgrading: composer dump-autoload, then restart PHP-FPM / php artisan optimize:clear. In long-running workers (Octane, Horizon) a moved helper file will not be re-read without a reload — restart the workers, don't just deploy.

Name collisions. A global arabify() function is fragile: if two packages or a legacy helper file define the same name, the load order in Composer's files array decides the winner, and the error surfaces as a fatal "cannot redeclare" at boot. Check composer.json's files order and grep your own app/ for a competing definition.

Static analysis and IDE support. Global functions are invisible to class-based autoloading and frequently trip PHPStan/Psalm ("function not found") and IDE completion. Either add a stub file to your analysis config or rely exclusively on your wrapper class — the wrapper is the better long-term answer.

Debugging checklist when arabify() is undefined:

1. composer dump-autoload -o
2. php -r "var_dump(function_exists('arabify'));" against the package's own vendor path
3. Inspect the package's composer.json autoload block and its service provider's register() for a require of the helper file
4. Check whether the provider is registered (php artisan about) — some packages ship the helper behind a config flag
5. grep -rn "function arabify" vendor/ to find where it actually lives now

Extension points. Rather than monkey-patching the helper, extend through the package's config (driver/locale) and through your own wrapper. If the package exposes a formatter contract or facade, bind your own implementation in a service provider — that survives helper relocation entirely.

Upgrade habit. For a package with 1.3.x patch releases that alter file layout, read the diff (composer diff or the GitHub compare view) rather than the changelog line. One sentence in a changelog rarely conveys whether a symbol's namespace changed.