andrey-helldar/beautiful-phone
Beautiful Phone is a Laravel/PHP package for formatting and displaying phone numbers cleanly. It offers convenient helpers to render readable, consistent phone output in Blade views and user interfaces, helping keep number presentation attractive and uniform across your app.
This release is small and additive, so onboarding is unchanged: composer require the package, publish its config (php artisan vendor:publish --tag=beauty-config or the tag listed in the README), and open the published config file first — it is the single place that governs formatting defaults across every "beauty" view in the app.
The fastest first use case is the one this release touches: render a value through a beauty view and confirm the number comes out formatted (thousands separators, decimals, currency/locale rules), then render the same view with formatting disabled to see the raw value. That side-by-side is the clearest way to understand what the package is actually doing for you before you wire it into real screens.
Where to look, in order:
Formatted display vs. raw value from one template. The headline feature in 2.2.0 — turning off number formatting per beauty view — removes the most common reason teams duplicate a Blade partial. The pattern to adopt: keep one view, and pass the formatting flag from the caller. Use formatted output for read-only presentation (dashboards, invoices, PDF exports for humans) and unformatted output for anything a machine or an input control will consume: hidden form fields, data-* attributes read by JS, CSV/Excel exports, API payloads, and editable inputs.
Per-view opt-out, not global opt-out. Treat the new switch as a narrow override and leave the config default as "formatting on." Flipping the global default to raw would silently degrade every existing screen at once; a per-view flag keeps the blast radius to the one template that needs it and makes the intent readable at the call site.
Round-tripping values. If a value is rendered unformatted into an editable field and re-submitted, validate and normalise on the way back in. The package formats for display only — it is not a parser, so do not assume 1.234,56 coming back from a user will be understood.
Configuration as the contract. After 2.2.0's configuration-access optimisation (087ae44), the resolved config is read more efficiently. Lean into that by centralising formatting decisions in config and per-view flags rather than scattering number_format() calls through your templates — one source of truth, and the package's optimised path actually pays off.
Integration tip. If you already wrap the beauty view in your own Blade component, expose the formatting flag as a boolean prop on your wrapper rather than letting callers reach into package internals. That keeps the package's option name in exactly one file, so a future rename is a one-line change for you.
Re-publish or diff the config. New options in a release frequently ship as new config keys. If you published the config months ago, your copy will not have them — diff the package's config against yours and merge by hand. Never blind re-publish over a customised config.
Clear the config cache. Configuration is now accessed through an optimised path, which makes stale cached config more visible, not less. After editing config run php artisan config:cache (and config:clear locally). A "my new option does nothing" report is almost always this.
Runtime config()->set() may not behave as you expect. Because the optimisation changes how config is read, code that mutates config at runtime and expects the next render to pick it up deserves an explicit test. Prefer passing the flag explicitly into the view; if you must mutate config, assert the behaviour in a feature test rather than trusting it.
Formatting off ≠ escaping off. Disabling number formatting returns the raw value — make sure it is still escaped in HTML context, and that any JS reading it handles the locale-independent decimal point. Raw output is the right choice for machines, but it moves the parsing burden to the consumer.
Debugging. When a value renders unexpectedly, dump the resolved options and the flag being passed at the call site before touching the package — nine times out of ten the flag is not what you think, or the config cache predates your edit. A single test that renders the view both ways is a cheap permanent guard.
Upgrade risk. Nothing in 2.2.0 is breaking: one additive option and one internal optimisation. The realistic failure modes are stale published config and any template that depended on incidental internals of the old config access. Run your view-rendering tests after upgrading; if you have none, add one per beauty view before you bump the version.
Extension points. Keep customisation at the edges — your own wrapper component, your own config values — rather than editing package views. If the per-view flag does not cover a case (e.g. you need different rounding per view), raise it upstream; the direction of this release suggests per-view knobs are the maintainer's preferred extension surface.
How can I help you explore Laravel packages today?