Laravel Num Laravel Package

Product Decisions This Supports

• Localization of customer-facing numbers. A small utility like this sits behind invoices, receipts, contract PDFs, checkout totals, and statements — anywhere a raw number has to become something a customer reads. v2.0.0 keeps that capability available to us on a current Laravel stack rather than freezing it on an end-of-life framework.
• Platform upgrade sequencing. The release is essentially a compatibility signal: Laravel 13 support added, Laravel 9 and 10 dropped, PHP < 8.2 dropped. That makes it a dependency we can carry through a Laravel 11/12/13 and PHP 8.2+ modernization rather than a blocker we have to fork or replace mid-programme.
• Build vs. buy. Number-to-words and locale-aware digit/amount formatting are low-differentiation, easy to get subtly wrong (rounding, currency symbols, thousands separators, non-Latin numerals). Buying a maintained package is cheaper than owning that logic — but only while the package tracks the framework versions we run.
• Roadmap gating for new work. Any feature team planning localized output (multi-country billing, regional storefronts, translated statements) should treat this package as an approved dependency only on Laravel 11+; teams still on 9/10 must either stay pinned to v1.4.0 or upgrade the platform first.
• Not a decision driver on its own. This is a convenience dependency, not a strategic bet. It should not consume roadmap capacity beyond a routine compatibility bump and a periodic health check on maintainership.

When to Consider This Package

Consider adoption when:

• The application is on Laravel 11, 12, or 13 and PHP 8.2+ — the only supported combinations after v2.0.0.
• You need formatting behaviour that Laravel's built-in Number facade does not cover — most commonly number-to-words (legal amounts on invoices/contracts) or locale-specific digit rendering.
• You want that capability as a thin, framework-native dependency rather than hand-rolled helper functions scattered across the codebase.
• You are comfortable with a small, single-maintainer package for non-critical presentation output — worst case, a formatting regression is visible and fixable, not data-destroying.

Look elsewhere (or stay pinned) when:

• You are still on Laravel 9 or 10, or PHP < 8.2. v2.0.0 is a hard break; stay on v1.4.0 and treat the upgrade as part of the platform migration, not a standalone bump.
• Laravel's native Number helpers or the PHP intl extension already cover your needs. Adding a dependency for formatting you already have is unnecessary surface area.
• You need broad CLDR/ICU locale coverage, currency conversion, or heavy internationalization guarantees. intl/NumberFormatter is the more defensible foundation.
• The output is financial-grade or regulatory (tax filings, statutory disclosures). Verify rounding and wording behaviour against requirements first; don't inherit it from a utility package by default.
• You require long-term vendor support, SLAs, or security review of every dependency — a small community package likely fails that bar.

Release-specific caveat to verify before adoption: the v2.0.0 notes say Laravel 9, 10 "and 10" are dropped, which is ambiguous about Laravel 11. Confirm from composer.json that 11 and 12 remain in the constraint before assuming a drop-in upgrade path from v1.x; if 11 is also dropped, the jump is effectively Laravel 12+ only and should be scoped accordingly.

How to Pitch It (Stakeholders)

For executives (one paragraph): We depend on a small open-source Laravel package for formatting numbers in customer-facing documents — amounts written out in words on invoices and contracts, and locale-correct digits on receipts. Its new major version simply keeps it current: it adds support for the newest Laravel release and drops support for older framework and PHP versions we are already moving off. There is no new functionality and no cost. The practical effect is that this dependency will not block our platform upgrade; the only work is a version bump timed with that upgrade, plus a note that any team still on the older framework must stay on the previous release until they migrate.

For engineering:

• v2.0.0 is a breaking release, but only in requirements — no API or behaviour changes are described. Treat it as a compatibility bump: laravel/framework support moves to current versions, php constraint to ^8.2.
• Action: align the bump with the Laravel/PHP upgrade PR rather than shipping it separately; on Laravel 9/10 or PHP < 8.2, pin to ^1.4.0 and add a TODO on the migration ticket.
• Verify before merging: read composer.json for the exact framework constraint (the changelog's "9, 10, and 10" is ambiguous about 11) and confirm the CI matrix covers the versions we actually run.
• Guard the risk: this is presentation-layer output with a single maintainer. Keep usage behind our own thin formatter service or Blade component so the package can be swapped or replaced with intl without touching call sites, and add a test asserting the exact rendered output for a representative invoice amount so a future release can't silently change customer-visible text.