Laravel Readable Laravel Package

Technical Evaluation

Architecture fit — Strong (isolated presentation concern). pharaonic/laravel-readable is a stateless formatting utility: human-readable numbers, dates, relative times, durations, and file sizes exposed as static methods, global helpers, and Blade directives. It touches no database, queue, cache, or storage layer. That means it slots into the presentation layer only — Blade views, mail templates, Nova/Filament columns, API resource transformers at the outermost boundary. It should be treated as a view concern and explicitly not used in domain logic, money arithmetic, or persisted values, because these helpers are lossy by design (rounding, locale-dependent strings).

The package is a thin façade over Carbon (diffForHumans, localization) and PHP's intl/NumberFormatter for number and size formatting. Functionally, most teams already have this capability; the package's value is consistency and reduced boilerplate, not new capability. Integration surface is small: one service provider with auto-discovery, an optional publishable config, and a set of global helpers/directives.

Integration feasibility — Easy, under a day. composer require + auto-discovery is the whole install. Two things need verification before we commit:

1. Global helper registration — the package loads namespaced-or-global PHP functions. Global functions are a collision and testability hazard, and there is typically no opt-out flag.
2. ext-intl dependency — number/size formatting almost certainly requires intl. If it's a hard requirement rather than a soft fallback, our Docker/CI images and any shared-hosting-adjacent environments must add it.

Technical risk — Low blast radius, elevated provenance risk. The code is read-only formatting; a defect produces wrong-looking strings, not corrupted data or downtime. The real risks are supply chain and abandonment:

• "Repository: unknown" is the headline finding. We cannot verify source, CI status, test coverage, maintainer identity, or that the Packagist artifact matches any public source. This is a conditional blocker — do not adopt until we can diff the published package against a verifiable upstream, or vendor it into our own tree.
• 23 stars / bus-factor 1 — this is a single-maintainer convenience package. Expect eventual abandonment. Mitigation is cheap: the entire value proposition is a few hundred lines over Carbon and NumberFormatter, so a vendored internal App\Support\Format class is a realistic exit.
• Release date anomaly — the listed last release (2026-10-11) post-dates the assessment. Treat the metadata as unreliable; confirm the actual tagged version and changelog on Packagist directly.
• Composite score of ~19/100 is consistent with "small, low-adoption, unverified-source utility." That score is a proxy for due-diligence friction, not for code quality — and here the friction is concentrated entirely in provenance and longevity, not in runtime behavior.

Key questions for the maintainer / due diligence

1. Where is the canonical repository, and does the tagged release on Packagist correspond to a signed/verifiable commit?
2. Is ext-intl a hard composer.json requirement? What is the fallback behavior when it's absent — exception, English-only, or silent garbage?
3. Which locale does each helper resolve: app()->getLocale(), Carbon::getLocale(), a per-call argument, or a config default? Do the numbers and dates share a locale source?
4. Are Blade directives compiled to cached-safe PHP? Do they escape output, or echo raw (an XSS consideration if ever fed user-controlled input)?
5. File-size semantics: base 1000 or 1024? Configurable precision? What does it do at boundary values (999.95 KB → "1000 KB" vs "1 MB")?
6. Supported Laravel/PHP version matrix, and is there CI against the versions we run?
7. Is the global helper set namespaced, and can helper autoloading be disabled?
8. Relative-time correctness: what timezone does it diff against, and is it DST-safe (Carbon handles this; a hand-rolled impl may not)?

Integration Approach

Stack fit. Compatible with any modern Laravel application (PHP 8.x, Laravel 9–11 expected, to be confirmed). No conflict with Livewire, Inertia, or API-first architectures — but note that in an Inertia/SPA or mobile-client architecture, server-side formatting is the wrong layer: ship ISO-8601 timestamps and raw byte counts and format client-side with Intl.NumberFormat/Intl.RelativeTimeFormat. This package is only a fit for server-rendered Blade and email.

Migration path. Nothing to migrate from unless we already have ad-hoc formatting scattered across views — in which case the migration is the point: inventory existing number_format(), Carbon::diffForHumans(), and hand-rolled byte formatters, and consolidate them behind this package (or behind our own wrapper around it).

Recommended adoption pattern — wrap, don't sprinkle.

1. composer require pharaonic/laravel-readable pinned to an exact version (not a caret range), with composer.lock committed.
2. Publish and commit the config file so locale/precision defaults are code-reviewed rather than implicit.
3. Create a thin internal adapter — App\Support\Format — that delegates to the package. All views call our adapter. This gives us a one-file swap to a native Carbon/NumberFormatter implementation if the package is abandoned, and a single place to enforce escaping and locale policy.
4. Vendor the package source into the repo if legal/procurement review objects to the unverified repository (MIT permits this; retain the license header and attribution).

Compatibility checks before merge.

• Confirm ext-intl in composer.json and add it to the Dockerfile and CI matrix.
• Scan for global helper name collisions against existing app helpers and other packages.
• Verify behavior under APP_LOCALE values we actually ship (e.g., en, de, fr, ar) — pluralization and relative-time phrasing are the usual failure points.
• Confirm the Blade directives survive php artisan view:cache and don't break under Octane's long-lived workers (static state is the thing to check).

Sequencing.

1. Spike (0.5 day) — install in a branch, exercise every helper across our locales, capture outputs as a golden-file fixture.
2. Provenance gate (0.5 day) — locate upstream, verify tag↔commit, review source for anything beyond Carbon/intl delegation. If it fails, vendor or reimplement (est. 1 day).
3. Adapter + tests (1 day) — App\Support\Format wrapper with unit tests over the golden fixtures.
4. Pilot (0.5 day) — one low-risk surface, e.g., an admin dashboard and one transactional email template.
5. Rollout (ongoing, opportunistic) — replace ad-hoc formatting as files are touched; no big-bang refactor.

Operational Impact

Maintenance — Near zero, but ownership is the question. Runtime maintenance is trivial: no migrations, no cron, no config drift, no data. The maintenance burden is organizational — tracking an unverified-source, single-maintainer dependency in our SBOM and re-reviewing it at each Laravel major upgrade. Budget ~2 hours per Laravel major for compatibility validation.

Support — Weak upstream, strong internal fallback. With 23 stars and an unverifiable repository, there is effectively no community support channel and no expectation of a timely CVE response. Our mitigation is structural, not contractual: the adapter boundary plus a documented 1-day reimplementation path means our support story doesn't depend on the maintainer. Do not adopt without that boundary in place.

Scaling — Non-issue. Pure CPU string formatting, microsecond-scale, no I/O, no shared state, no allocation pressure beyond the return strings. Safe under Octane and in high-fan-out Blade rendering. Only caveat: avoid calling relative-time helpers in tight loops over large collections where a single "now" reference would do — otherwise the clock can advance mid-render and produce inconsistent output within one page.

Failure modes and mitigations

Ramp-up — Under a day for any Laravel developer. The API is self-describing and mirrors concepts engineers already know from Carbon and NumberFormatter. The only real onboarding item is the team convention: always call App\Support\Format, never the package directly, never in domain code.

Recommendation. Conditional go. Technically this is a low-risk, low-effort, low-ceiling convenience package that fits cleanly into the Blade layer. But its ~19/100 composite score, 23 stars, and unverified repository mean the decision hinges on a half-day provenance review, not on engineering merit. If upstream can be verified, adopt behind an adapter and pin the version. If it can't, reimplement the handful of formatters natively over Carbon and NumberFormatter — the cost is roughly one engineer-day, and it eliminates the dependency risk entirely while preserving 100% of the value.