Bytesize Laravel Package

Product Decisions This Supports

• Presentation-layer features that need human-readable sizes. Any surface that shows bytes to a human — file managers, upload dialogs, storage/quota screens, usage dashboards, log viewers, attachment lists, API responses, admin panels — needs consistent formatting (e.g., 1.5 MB vs 1536 KB vs 1572864). This package is a candidate for that one job.
• Build vs. buy for commodity utilities. The decision it most directly informs is whether to add a dependency for a ~30-line formatting concern versus inlining a helper. At 31 stars, zero dependents, and a last release in 2014, the honest answer trends toward build (or vendor a maintained alternative), which is itself a useful decision to document.
• Consistency standards across the product. Whether sizes render as SI (1000-based) or binary (1024-based), how rounding is handled, and whether units are localized are product decisions. Adopting a library fixes those defaults, for better or worse — worth deciding deliberately so different teams don't ship MB vs MiB inconsistently.
• Low-priority roadmap items. Quota displays, storage insights, and "usage this month" widgets are typically roadmap-fillers, not differentiators. A tiny formatter library lowers the cost of shipping them without committing engineering time — but should not be treated as architecture.
• Risk register / dependency policy. The package's age and inactivity make it a data point for decisions about how the org treats abandoned dependencies (tolerate, vendor, or replace) and whether transitive risk is acceptable for non-critical utilities.
• Not supported: pricing, packaging, growth, or platform strategy. This is a formatting utility with no network, storage, or business-logic surface — it should not influence product direction.

When to Consider This Package

Consider it when:

• You need simple, one-way formatting of an integer byte count into a display string, and nothing more (no parsing, no localization, no unit policy configuration).
• You're working in a legacy PHP codebase that already depends on it, where replacing it has non-zero cost and near-zero benefit.
• You want a zero-dependency, MIT-licensed helper small enough to read and audit in minutes — the entire library is trivially reviewable, which offsets some of the abandonment risk.
• The output is cosmetic and non-critical: a misformatted size in an admin table is a nuisance, not an incident.

Look elsewhere (or build it) when:

• Maintenance matters. No release since April 2014 means no PHP 8 compatibility guarantees, no security patching, and no upstream responsiveness. A 30-line formatBytes() helper you own is likely cheaper over a multi-year horizon than carrying an abandoned dependency through framework upgrades.
• You need more than formatting. Parsing user input ("1.5 GB" → bytes), configurable SI vs. binary units, precision rules, localization, or validation of size limits are all outside this package's scope.
• Your dependency policy requires active maintenance, automated vulnerability scanning, or a supported release cadence. Zero dependents also means no ecosystem signal that the code has been exercised in production at scale.
• You need framework integration (Laravel service provider, Blade directive, config publishing). This is a plain PHP library; you'd write the glue yourself.
• You need locale-aware output (comma decimal separators, translated unit names).
• You're evaluating for a platform-wide standard. For a formatting convention applied across many services, pick a maintained library or centralize your own helper rather than standardizing on an inactive one.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source PHP library for displaying file and storage sizes in human-readable form. It does one narrow thing well and is free to use, but it hasn't been updated since 2014 and has no meaningful adoption. Our recommendation is not to add it as a dependency: the same behavior is roughly thirty lines of code we can own outright, which removes an unmaintained component from our upgrade path at essentially no cost. This is a low-stakes, low-spend decision with no impact on roadmap or revenue.

For engineering:

• Scope: integer bytes → display string. No parsing, no i18n, no unit configuration. MIT licensed, zero dependencies, small enough to audit fully.
• Risk: unmaintained since 2014; no PHP 8 verification; no security response; zero dependents means no production track record to lean on. Low blast radius (cosmetic output) but a real long-term maintenance tax during framework upgrades.
• Recommendation: implement a small internal helper with tests covering rounding, unit thresholds, and edge cases (0 bytes, negative/invalid input, very large values), and standardize SI vs. binary units product-wide. If we later need parsing or localization, we'll evaluate a maintained library rather than extending this one.
• If we do adopt: vendor or pin it, wrap it behind our own interface so it's replaceable in one place, and exclude it from any code path that affects billing, quotas enforcement, or customer-facing contracts — display only.