Laravel Formatters Laravel Package

Product Decisions This Supports

• Presentation consistency as a product-quality decision. Every customer-facing surface — transactional emails, invoices/PDFs, admin tables, API payloads, exports — formats the same values (money, dates, phone numbers, names, IDs). This package gives you a named, single place for those rules, so "why does the invoice show $1,200.00 and the dashboard show $1.2k?" stops being a recurring bug class.
• Localization / market-expansion roadmap. Centralized formatters are the cheapest possible seam for adding a second locale or currency. If internationalization is on the 2–4 quarter horizon, adopting a formatter layer now is a down-payment that makes the later i18n epic a config change rather than a codebase-wide refactor.
• Build vs. buy (and the honest answer: neither). The package is a thin pattern skeleton — a contract, a base class, invokable formatter objects, container bindings — not a formatting engine. The value is the convention it enforces, not the code. That makes the build-vs-buy calculus unusual: adopting it is cheap, and internalizing it later is also cheap (~1 day). Treat it as "buy a convention, keep an exit."
• Rounding and disclosure policy. Money display rules (rounding, separators, negative formatting, currency symbol placement) are a finance/compliance surface, not a cosmetic one. A formatter abstraction is where you enforce those rules once and make them auditable.
• Team-convention decision. If your codebase currently scatters number_format(), Carbon::parse()->format(), and inline string concatenation across controllers, models, and Blade, this is a candidate standard to put in your engineering guidelines — with or without the package.
• Scope discipline. Because it's presentation-only and framework-native, it slots in without touching the domain layer, which means it can be adopted incrementally, per-domain (start with money, then dates), without a migration project.

When to Consider This Package

Adopt when:

• You can point to three or more places in the codebase formatting the same domain value differently, or a bug ticket that came from exactly that.
• You're on a supported Laravel version with a modern PHP runtime and the team is already comfortable with container-resolved, invokable single-purpose classes.
• Your team already buys into "pattern packages" (interfaces + base classes + service provider) as a house style — the maintainer publishes a family of these, so it will feel idiomatic rather than exotic.
• You want the convention codified with a real namespace and test surface rather than a app/Support/helpers.php grab bag.
• You want the option to swap the implementation later without rewriting call sites.

Look elsewhere when:

• You have exactly one formatting need. Laravel's built-in Number/Str helpers and Carbon's formatters already cover a large slice of this. Adding a dependency for a single Number::currency() call is overkill.
• You need real locale-aware formatting. If you're shipping to multiple locales with CLDR-correct number, currency, and date output, the correct primitive is PHP's intl / NumberFormatter — this package is a wrapper pattern, not a locale engine.
• You need money arithmetic, not money display. Use moneyphp/money or brick/money for the value-object and math layer; a formatter is the presentation step downstream of that.
• Your dependency governance requires maintenance SLAs. 94 stars, zero dependents, and a single maintainer mean you are, functionally, the only production user you know of. If your policy gates on adoption breadth or vendor support, this will fail the gate — and that's a legitimate outcome.
• You're not willing to own a fork. At this size, assume you may have to patch it yourself one day. If "we can vendor a 300-line package" isn't acceptable to your org, don't start.
• The team won't maintain the convention. A formatter package nobody routes through is worse than no package: it's an unused dependency plus an inconsistency.

How to Pitch It (Stakeholders)

To executives (30 seconds):

We have a small, recurring class of defects where the same number or date renders differently on different screens — invoices vs. dashboards vs. exports. This is a ~free fix: a tiny MIT-licensed Laravel package that gives us one named place to define how we present money, dates, and contact data. It costs nothing, adds no infrastructure, and if we ever want to drop it, replacing it is roughly a day of work. The real output is a team standard, not a vendor relationship.

To engineering (the honest framing):

It's an interface + abstract base class + a handful of invokable formatter classes, resolved from the container. No runtime overhead, no data-layer coupling, no magic. It gives us a typed seam for presentation logic so formatting stops living in Blade templates and controllers. Two caveats we should accept up front: (1) it's a single-maintainer package with effectively no public dependents, so we pin the version and keep our formatters behind our own namespace so swapping is trivial; (2) it is not a localization or money-math library — if we need CLDR-correct multi-locale output, we wrap intl inside these formatters rather than expecting the package to do it.

Recommendation: Adopt narrowly — one domain (money display), one sprint, behind an in-house namespace — and measure whether formatting-related inconsistencies stop appearing. If they do, expand to dates and contact data. If the package's surface gets in the way, keep the convention and delete the dependency; that's the cheapest possible failure mode, which is exactly why it's worth trying.