Hashcli Laravel Package

Getting Started

cr/hashcli is a standalone CLI binary, not a Laravel service provider — there's no facade or config file to publish. Install it as a dev dependency or globally:

composer require --dev cr/hashcli
# or, for use outside a single project:
composer global require cr/hashcli

Look first at the bin entry in the package's composer.json (usually vendor/bin/hashcli) and run --help before anything else. The flag surface is small and the README may lag the code, so --help is the source of truth for argument order:

php vendor/bin/hashcli --help

Your first and most common use case is generating a bcrypt hash to paste into a seeder, fixture, or .env, and verifying a stored hash without opening Tinker:

php vendor/bin/hashcli hash 'secret123'
php vendor/bin/hashcli verify 'secret123' '$2y$10$...'

If those subcommands don't exist as written, the interface is almost certainly positional (hashcli 'secret123'), so check --help before assuming a bug. Confirm it uses PHP's native Hash/password_hash under the hood — if the source implements any custom crypto, stop and use Hash::make() directly.

Implementation Patterns

Seeder / fixture generation. Avoid hardcoding bcrypt strings — they rot when cost factors change. Generate at seed time:

HASH=$(php vendor/bin/hashcli hash "$SEED_PASSWORD")

Feed that into your seeder via env var, or call the binary from a helper so it's swappable for Hash::make().

Deployment and provisioning. Because it's a clean process with an exit code, it slips neatly into shell scripts — mint an admin hash during deploy.sh and hand it to db:seed:

ADMIN_HASH=$(php vendor/bin/hashcli hash "$ADMIN_PASSWORD") \
  php artisan db:seed --class=AdminSeeder

Prefer stdin-piped or interactive mode for anything sensitive; argv shows up in ps and often in shell history.

CI / health-check smoke test. Hash a known string, verify it, and assert success — a cheap pre-deploy gate that catches extension drift or PHP version divergence that unit tests using Hash::make() can mask.

Wrapping in an Artisan command. If your team just wants a named command, write the one-file wrapper rather than teaching everyone a vendor path:

public function handle(): void
{
    $this->line(Hash::make($this->argument('password')));
}

This is frequently the better trade — see below. If you do want the binary's behavior without the path, wrap it behind a small HashCliAdapter class so you can swap the implementation for native Hash:: calls later without touching call sites.

Invoking from application code. Use Symfony\Component\Process\Process rather than shell_exec, with a timeout and output validation:

$process = new Process([PHP_BINARY, base_path('vendor/bin/hashcli'), 'hash', $value]);
$process->setTimeout(5);
$process->mustRun();
$hash = trim($process->getOutput());

Pass arguments as an array — never string-concatenate shell commands with user input.

Gotchas and Tips

It's a separate process, not a library. Every invocation pays PHP bootstrap cost — fine for a seeder, wrong for a request path. Runtime hashing belongs in application code via Hash::make(). The CLI is for humans and scripts.

Security-adjacent dependency hygiene. Hashing sits next to credentials. If you adopt this, pin the version, run composer audit in CI, and read the (short) source to confirm it only wraps native functions. Better still: vendor or copy the ~30 lines into an internal command you own — the substitutability is total.

Don't route production password storage through it. No Argon2 tuning, no algorithm agility documented, no key rotation, no maintenance SLA. For real auth, use Hash::make() / password_verify() directly or symfony/password-hasher. Use the CLI for local fixtures and one-off checks only.

Secrets leak via argv. ps aux, shell history, and CI logs all capture command arguments. Check whether the tool accepts stdin or prompts interactively; if not, prefer piping where supported and treat output as sensitive.

Environment parity. The binary resolves the PHP interpreter and extensions from whatever runtime shells out to it. In containers this may not be the same PHP as your app — mismatched versions or a missing sodium extension produce silently different hashes. Verify with a hash-then-verify round trip in CI rather than assuming.

Parse exit codes, not output. If you're scripting, branch on the exit status and validate output shape (e.g., a $2y$ prefix) rather than trusting human-readable messages. The interface may change between versions; exit codes are more stable.

Large inputs. If you're hashing files, verify the tool streams rather than loading into memory — hash_file()-style support isn't guaranteed by the description. For big artifacts, shell out to sha256sum or use hash_file() directly.

Extension point is absence. There's nothing to extend — no provider, no facade, no config. That's the point: treat it as a reference implementation, pin it, and keep the replacement path (native PHP functions) one adapter swap away.