Getting Started

andrey-helldar/pretty-array is a tiny, framework-agnostic helper that turns a PHP array into a human-readable, syntax-coloured dump — primarily as an HTML <pre> block. There is no service provider, no facade, and no config to publish, so "installation" is just Composer:

composer require andrey-helldar/pretty-array

Where to look first, in this order:

README.md — the entire public API is demonstrated there in a handful of lines.
src/ — it is small enough to read in one sitting; the formatter class (the thing you actually call) and the helper file, if the version ships one, are the only files that matter.
composer.json — check the php constraint and whether a files autoload entry exists (i.e. whether a global helper function is registered).

The first use case is almost always "I need to show a config array or an API payload to a human without leaving the app." A typical call looks like a small formatter service that accepts the array and returns HTML. Confirm the exact signature against the README for your pinned version — the package is archived, so the README is the specification:

use AndreyHelldar\PrettyArray\Services\Formatter;

$html = Formatter::make()->pretty($payload);

// or, if the helper is autoloaded:
$html = pretty_array($payload);

Because output is HTML, the natural home is Blade:

@if (app()->isLocal())
    <div class="debug-array">{!! pretty_array($config) !!}</div>
@endif

Treat the package as a development and admin-facing presentation tool, not a production rendering primitive. If you only need a quick look, dump() / dd() / ray() already exist; this package earns its place when you want a persistent, styled, non-halting dump embedded in a page, an emailed debug report, or an internal config viewer.

Archived status matters. With 17 stars and no upstream maintenance, pin an exact version (composer require andrey-helldar/pretty-array:1.2.3 style) or commit composer.lock, and prefer a small wrapper class of your own (see below) so replacing it later is a one-file change.

Implementation Patterns

Wrap it once. The single most valuable pattern with a package this small is to never call it directly from views or controllers. Put one class in front of it:

namespace App\Support;

use AndreyHelldar\PrettyArray\Services\Formatter;

final class ArrayDump
{
    public static function toHtml(array $data): string
    {
        if (! app()->isLocal() && ! auth()->user()?->isAdmin()) {
            abort(404);
        }

        return Formatter::make()->pretty($data);
    }
}

This gives you one place to swap in Symfony VarDumper, json_encode($data, JSON_PRETTY_PRINT), or a forked version when the package inevitably breaks on a future PHP release.

Dev-only route for config inspection. A very common day-to-day use is a signed, local-only route that renders config('services') or an environment snapshot:

Route::get('/_debug/config/{key}', function (string $key) {
    abort_unless(app()->isLocal(), 404);

    return view('debug.array', [
        'html' => ArrayDump::toHtml(config($key)),
    ]);
})->where('key', '[a-zA-Z0-9_.]+')->middleware('auth');

Blade component for reuse. Turn it into <x-array-dump :data="$payload" /> with the component doing the local/admin guard and wrapping the output in a styled container. This keeps raw {!! !!} out of your feature views.

Console/CLI variant. Note that an HTML <pre> dump is not useful in Artisan output. For terminal work, either strip the markup (strip_tags(), and accept that you lose colour) or guard on app()->runningInConsole() and fall back to Symfony\Component\VarDumper\Cloner\VarCloner or json_encode(..., JSON_PRETTY_PRINT). Do not mix the two paths silently — the output formats diverge and confuse people.

Integration in exception/mail reporting. Because the output is a self-contained HTML string, it composes well into a Mailable body for cron diagnostics:

Mail::raw('', fn ($m) => $m->to(config('mail.debug_to'))->html(ArrayDump::toHtml($context)));

Data-shape guard before calling. Normalise anything non-array first — models, collections, DTOs — with ->toArray() or json_decode(json_encode($dto), true). Passing objects into an array formatter is where this package is least forgiving.

Snapshot-style assertions (carefully). You can assert against the rendered string in tests to lock down config shapes, but the markup is an implementation detail of an archived package. Prefer asserting on the data (assertSame($expected, config('foo'))) and use the formatter only when debugging a failing test.

Gotchas and Tips

Archived means frozen. No upstream fixes for PHP version bumps, XSS reports, or deprecations. Vendor-patch if needed ("type": "vcs" fork) rather than relying on an upstream tag that may never come. Add a composer outdated check to your routine.
HTML output + unescaped user data = XSS. Any array containing user-supplied strings will be embedded in the markup. Escape before formatting if the source is untrusted, and never render this outside local/staff-only contexts. This is the biggest footgun with a "pretty print" package.
{!! !!} in Blade. The ergonomics push you toward unescaped output. Keep it confined to the wrapper class/component described above, and grep for pretty_array( / PrettyArray before merging to ensure no stray calls leaked into feature views.
Type handling is shallow. Closures, resources, and some objects may be cast to string, throw, or render as Object. Recursive arrays (self-references) can be a problem — if you get an infinite loop or a memory blow-up, you fed it a cyclic structure; convert to a flat representation first.
Large arrays are not truncated. Unlike VarDumper, there is usually no depth or item limit. Dumping a 10k-row result set will produce a multi-megabyte page and can time out the request. Cap or slice (array_slice($data, 0, 200, true)) before formatting.
Styling collisions. Colour comes from inline styles or markup classes that can be overridden by your app's CSS resets or Tailwind preflight. If the output looks unstyled, that is why — scope it inside a container with explicit styles.
Global helper conflicts. If the version registers a pretty_array() function via Composer files autoload, it can collide with an app helper or another package. Check vendor/andrey-helldar/pretty-array/composer.json for the files key; if present, the collision surfaces as a fatal "cannot redeclare function" at boot.
No facade / no auto-discovery. Don't write PrettyArray::make() expecting an alias. Use the FQCN or your own wrapper. There is nothing to php artisan vendor:publish.
Console vs browser. PHP CLI does not interpret HTML, and terminal colour codes will not render inside <pre>. Branch on the environment rather than shipping one format to both.
Extension points are thin. The realistic customisation is (a) subclass or decorate the formatter and (b) post-process the string (wrap in your own container, strip_tags, transform). Don't expect a config file or renderer interface.
Debugging the debugger. If you get an empty string back, first confirm the argument is a non-empty array (not a Collection or Arrayable), then check the return value of the formatter method against the README — small packages often have both a "return" and an "echo" path and it is easy to call the wrong one.
Decision point. For anything beyond a static dump in a local view, Symfony VarDumper (dump()/dd()), Laravel's own dump, or ray() give you truncation, depth control, and active maintenance. Choose this package only if you specifically need a plain string of styled HTML you can store, email, or embed.

Pretty Array Laravel Package

Getting Started

Implementation Patterns

Gotchas and Tips