Console Components Laravel Package

Getting Started

The 1.0.4 release is a patch-level dependency alignment — it widens/updates support for laravel/prompts (PR #1 by @JustinByrne, first-time contributor). There are no new public APIs, no deprecations, and no breaking changes. You do not need to change application code; a composer update uttamrabadiya/console-components is sufficient. The main practical consequence is that composer update may now resolve a newer laravel/prompts minor version than before, so re-run your command test suite if you assert on prompt output.

Minimal steps:

composer require uttamrabadiya/console-components

The package targets modern Laravel (PHP 8.1+, Laravel 10/11) and depends on laravel/prompts, which Laravel already ships with. There is no install/publish step described, so treat it as zero-config until the README says otherwise.

Where to look first, in order:

1. README.md — the component inventory (the exact class/method names matter more than anything else here; the package is a thin presentation layer, so the surface area is small and the README is the whole API).
2. src/ — one class per component is the likely layout. Skim the constructor signatures to see which take a string vs. an array of rows.
3. tests/ — the fastest way to see components used end-to-end in a real command, including what the expected terminal output looks like.
4. composer.json — confirm the laravel/prompts constraint after upgrading, and check extra.laravel.providers for auto-discovery.

First use case: take an existing Artisan command that currently spits out raw $this->line() calls and replace its output block with the package's components. A typical before/after:

// before
$this->line('Importing users...');
$this->line('Done. 412 imported, 3 failed.');

// after (verify exact method names in the README)
$this->components->info('Importing users...');
$this->components->table($headers, $rows);
$this->components->success('412 imported');
$this->components->error('3 failed');

That single command is enough to evaluate whether the components earn their keep over $this->components (Laravel's built-in) and raw Prompts.

Implementation Patterns

Wrap it in a base command. The highest-leverage pattern is a project-local BaseCommand that composes the package's components behind your own stable method names ($this->banner(), $this->summary()). Component packages at 1.x move fast; a base class means a minor bump changes one file, not forty commands.

Keep output and logic separated. Build your data first, then render. This makes the components swappable and lets you test the logic without touching terminal formatting:

public function handle(UserImporter $importer): int
{
    $result = $importer->run();      // pure-ish, testable

    $this->renderSummary($result);  // all component calls live here
    return $result->failures ? self::FAILURE : self::SUCCESS;
}

Use it for multi-step/progress narratives. The package's value is highest where a command has phases — fetch, transform, write, verify. Render a header per phase, a table or list for per-item results, and a terminal success/error line. For single-line commands, $this->info() is still fine; don't add a dependency to every command.

Integration with Laravel's built-in $this->components. Laravel already exposes components->info(), ->task(), ->twoColumnDetail(). Use the built-in for standard lifecycle output and the package for the richer visual components the built-in lacks (tables with styling, panels, badges). Mixing both in one command is fine as long as the visual language is consistent.

Testing. Two layers:

$this->artisan('users:import')
    ->expectsOutputToContain('412 imported')
    ->assertSuccessful();

Assert on substrings, not full formatted lines — boxes, padding, and ANSI codes will break exact-match assertions on any minor bump. For interactive prompts, use Prompts::fake([...]) (Laravel's helper) rather than stubbing the package directly.

CI and non-interactive contexts. Guard decorative output so scheduled jobs and CI logs stay readable (see gotchas below).

Gotchas and Tips

Prompts only render interactively. laravel/prompts — and therefore anything built on it — degrades or no-ops when stdout isn't a TTY or when --no-interaction / -n is passed. Since 1.0.4 changes the Prompts support surface, re-verify both paths after upgrading: run the command once by hand and once as php artisan your:command -n < /dev/null and confirm you get sensible plain output rather than an exception or a hanging prompt. This is the most likely place a Prompts-version bump bites you.

Piping and redirection. php artisan cmd | grep foo or writing to a log file will strip box drawing and may suppress prompt rendering entirely. If the command's output is consumed by a script, emit machine-readable output (--json) and reserve these components for humans.

Detect interactivity explicitly. Rather than sprinkling if statements, centralize it:

$decorated = $this->output->isDecorated() && ! $this->option('no-interaction');

Then have your base-class wrappers fall back to $this->line() when $decorated is false. This one helper prevents the majority of "the boxes look broken in CI" bug reports.

Don't assert on formatting in tests. Covered above, but it bears repeating as a tip: assert on semantics (expectsOutputToContain) so patch releases like 1.0.4 never fail your suite.

Pin the version, at least loosely. You're on 1.x with a small contributor base and a dependency-driven release cadence. Use "uttamrabadiya/console-components": "^1.0" and commit composer.lock. Don't use dev-main for anything that ships.

Watch the transitive Prompts upgrade. Composer may now pull a newer laravel/prompts than you previously resolved. If your own code calls Prompts helpers directly, check the changelog for that package too — the 1.0.4 change is on the consumer side, but the version floor moved.

Windows / non-ANSI terminals. Box drawing and emoji rendering vary across Windows terminals and older SSH clients. If your users span platforms, test in cmd.exe or set $this->output->setDecorated(false) in a smoke test. Emoji in status markers is the usual culprit for garbled output.

Where to extend. Since this is a presentation layer, extension should be outside the package: subclasses of your base command, or a thin view-model that produces the arrays you feed into table/list components. Avoid patching vendor code — there's no evidence of a publishable config or view layer here, and if there is one, vendor:publish it so your customizations survive composer update.

Debugging a component that won't render: check in this order — (1) is stdout a TTY, (2) did -n get passed, (3) does the input array contain nulls or nested arrays the component doesn't expect, (4) is laravel/prompts resolving to a version outside the installed constraint (composer show laravel/prompts). Most "silent no-op" reports are (1) or (2).

Verdict on 1.0.4: adopt it; it's a safe patch. The absence of a documented Prompts version floor in the release notes is the only mild annoyance — if you're mid-cycle on a large upgrade, take a five-minute look at the diff for composer.json before pulling