Cli Laravel Package

Getting Started

Install and confirm what you actually have

composer global require aerocommerce/cli
export PATH="$PATH:$HOME/.composer/vendor/bin"   # or ~/.config/composer/vendor/bin
aero list

Prefer a per-project dev dependency (composer require --dev aerocommerce/cli) over a global install once more than one developer or CI runner is involved — v0.4.x is pre-1.0, so pinning the version in composer.json/composer.lock is the only way to get reproducible behaviour across machines.

Look here first, in this order

1. aero list and aero help <command> — the command surface is small, and the help output is the most reliable documentation this package has.
2. The release notes (v0.4.6 adds --no-interaction to aero commands) — that single line tells you the intended automation story.
3. The src/Command classes in the repo, if the README is thin. Since the package is essentially a thin Symfony Console wrapper around scaffolding + install steps, reading the command classes is faster than guessing at flags.

First use case: bootstrap a store

The day-one job is scaffolding a new Aero Commerce project (or wiring Aero into an existing Laravel app) without hand-running the same twenty setup steps every time. Run it once interactively in a scratch directory, capture the prompts and the resulting file layout, then codify that invocation as a script. That interactive run is your reference implementation — everything afterwards is about removing the human from it.

Implementation Patterns

Two modes, deliberately separated

• Interactive — a developer running aero ... locally to scaffold or repair an environment. Let it prompt; the prompts are the sanity check.
• Non-interactive — CI, Docker entrypoints, provisioning scripts. Always pass --no-interaction (-n) explicitly, even where the command looks harmless. Don't rely on the absence of a TTY to suppress prompts; you want deterministic behaviour, not environment-dependent behaviour.

Docker / CI entrypoint pattern

# entrypoint.sh
set -euo pipefail
aero <command> --no-interaction -vvv

Gate it behind a marker so it doesn't re-run on every container start (if [ ! -f storage/.aero-installed ]; then ... fi), because installer-style commands are rarely idempotent.

Wire it into composer scripts rather than asking humans to remember flags:

"scripts": {
  "aero:setup": "aero <command> --no-interaction"
}

This keeps the flag next to the version pin and gives you one place to change when the CLI's behaviour shifts.

Wrap, don't scatter

Put the invocation in a Makefile target or a bin/setup script. When the package is eventually abandoned (see below) or you fork it, you change one file rather than grepping YAML and Dockerfiles.

Extension point: project-specific commands

If you add your own aero-namespaced commands, register them through the application's console kernel and extend the package's base command class so they inherit the same input/output conventions and honour --no-interaction for free. Consistently calling $this->input->isInteractive() before any prompt is the discipline that makes this work.

Environment guards

Installer commands that touch databases or config should refuse to run when APP_ENV=production. Add the guard in your wrapper script — don't assume the package provides one.

Gotchas and Tips

• It's effectively unmaintained. Last release February 2021, six stars, pre-1.0. Treat it as a fixed artefact: pin an exact version, commit the lockfile, and be prepared to fork or vendor it. Do not plan on upstream fixes.
• --no-interaction coverage is narrower than the release note implies. The note says "add no interaction to aero commands" — verify per command in a pipeline. Symfony's -n makes prompts return their defaults, which means a missing prompt becomes a silent wrong value (empty DB password, default store name, default admin email) rather than a loud failure.
• Non-interactive ≠ validated. After adding -n, assert the outcome in CI — check exit code and that the expected config/DB state actually exists. Exit code 0 with an empty DB_PASSWORD is the classic failure here.
• No TTY in containers. Prompts that don't respect -n will throw on a missing stdin rather than degrade. If you see hangs or Not enough arguments in Docker, that's the signal to look at which command is prompting.
• PATH and version drift. composer global binaries land in different directories across Composer 2.x setups; two developers on two global versions will get different generated projects. Per-project --dev install removes both problems.
• Platform coupling. The installer likely pins or scaffolds a specific Aero Commerce / Laravel / PHP version combination. Check the generated composer.json and PHP constraint before assuming it matches your existing app; a 2021-era CLI will not generate a current Laravel skeleton.
• Licensing is separate from the MIT code licence. Aero Commerce the platform may require a key or subscription. The CLI's MIT licence says nothing about whether the install completes without credentials — capture any such requirement before putting it in CI.
• Debugging: run with -vvv and --no-ansi in CI logs; exit codes are meaningful but stdout messages are terse. When a command "does nothing", add -v first — the package's dry-run/verbose story is minimal.