Symfony Console Bridge Laravel Package

Getting Started

The package is archived and essentially unmaintained, so treat it as a "read the source, pin the version" dependency rather than something you composer require casually. If you still want it in a Laravel app:

1. Pin it explicitly so a future composer update doesn't drift into another abandoned Hoa release:

   "require": {
       "hoathis/symfony-console-bridge": "^0.1"
   }
   

   (Check the actual constraint in the repo's composer.json — it likely targets hoa/console and an older symfony/console, and PHP 8 compatibility is not guaranteed.)
2. Look first at the Hoa\Console\Symfony namespace — the bridge's job is to adapt Symfony's InputInterface/OutputInterface to Hoa's stream-based console model. Read the adapter class and any Command subclass before writing anything.
3. Verify the bridge's symfony/console constraint against the version Laravel ships. If they conflict, you'll need composer why-not and possibly a replace fork; don't fight it silently.
4. First use case: an internal Artisan command that needs something symfony/console doesn't give you cleanly — terminal width/height, cursor save/restore, or a raw-line prompt with autocompletion. A typical minimal path is a command whose handle() uses Hoa\Console\Readline for an interactive prompt, then falls back to Laravel's normal output.

If you're just doing colors, tables, progress bars, or questions, stop here — Laravel's $this->components, laravel/prompts, and symfony/console helpers already cover it. The bridge earns its place only for low-level TTY work.

Implementation Patterns

Bridge a Symfony/Laravel command to Hoa primitives. Keep the Artisan command as the entry point and confine Hoa usage to the body of handle() (or a small helper class). This keeps the command discoverable by Laravel's command loader and testable up to the point where Hoa touches the terminal.

class TerminalUiCommand extends Command
{
    protected $signature = 'demo:ui';

    public function handle()
    {
        $window = new \Hoa\Console\Window();
        $this->line('Terminal is '.$window->getWidth().'x'.$window->getHeight().' cells');

        $readline = new \Hoa\Console\Readline\Readline();
        $answer = $readline->readLine('Name? ');
        $this->line("Hello, {$answer}");
    }
}

Adapt output explicitly. If the bridge exposes an output adapter, construct it from $this->getOutput() and hand it to Hoa, rather than letting Hoa write to php://stdout behind Symfony's back. That is the whole point of a bridge package — preserving Symfony's verbosity, decoration, and quiet flags. Verify which class does this in the repo; the namespace is the giveaway.

Wrap Hoa features behind small methods (terminalWidth(), promptInline()) so the rest of your commands stay Symfony-native. If the package dies — and it is archived — you can swap the implementation without touching call sites.

Compose with Laravel's native tooling. Use $this->components->info() for headings, $this->table() for data, then drop into Hoa only for the interactive/positional piece. Don't rewrite an entire command in Hoa's model.

Guard the TTY boundary. Every Hoa call that reads stdin, queries the window size, or emits cursor escapes should sit behind a check like stream_isatty(STDIN) / posix_isatty(STDOUT), with a non-interactive fallback path. This is also the seam you use for tests.

Register commands normally (app/Console/Kernel.php on Laravel ≤10, withCommands()/auto-discovery on 11+). There's no bridge-specific service provider or config file to register — it's a library, not a bundle.

Gotchas and Tips

• Archived + 19 stars + zero dependents is a real signal. No security patches, no PHP 8.x fixes, no Symfony 6/7 support. Audit composer.json constraints before assuming it installs alongside a modern Laravel. If it doesn't, vendor a fork or copy the ~one adapter class you actually need into app/Support/.
• Hoa packages carry PEAR-era baggage. Old hoa/* releases used unusual autoloading and sometimes needed the PEAR channel. If classes aren't found, check vendor/composer/autoload_psr4.php and confirm Hoa\ is mapped before debugging your own code.
• Direct stream writes break testing. $this->artisan('demo:ui')->expectsOutput(...) captures Symfony's output buffer; Hoa writing to STDOUT bypasses it. Tests will pass vacuously or hang waiting on stdin. Always force the fallback path in tests (check app()->runningUnitTests() or an env flag, or inject the TTY check).
• CI and piped contexts. Piped stdin (echo foo | php artisan demo:ui), Docker without a TTY, and most CI runners will make Readline and Window throw or return garbage. Catch Hoa\Console\Exception (and generic \Throwable at the boundary) and degrade gracefully.
• --quiet and --no-ansi are not respected by raw Hoa output. Cursor movement will corrupt logs or --quiet runs. Detect $this->output->isQuiet() and isDecorated() and skip Hoa rendering entirely in those cases.
• Windows support is weak. Hoa's cursor/window features assume ANSI/VT sequences and a Unix-ish terminal. If Windows matters, feature-flag it off.
• No config file. There is no config/symfony-console-bridge.php to publish. Anything you want configurable — TTY detection, fallback behavior — you build yourself. That's a legitimate extension point: a small ConsoleBridge service in your container that decides whether Hoa is safe to use.
• Debugging escape codes: when output looks mangled, pipe through cat -v or sed -n l to see raw sequences, and try script -q /dev/null php artisan demo:ui to fake a TTY locally. If you can't observe the bytes, you can't tell whether the bug is Hoa's or your adapter's.
• Prefer the boring alternative. laravel/prompts covers autocompletion and styled prompts; symfony/console covers cursor hiding via Terminal. Reach for the bridge only for the narrow set of window/stream operations those don't expose — and expect to own that code forever, since upstream won't.