Silly Laravel Package

Product Decisions This Supports

• Build-vs-buy for every internal CLI surface. Silly collapses Symfony Console's ceremony (configure(), execute(), argument/option wiring, input validation) into a single $app->command('greet [name] [--yell]', fn(...) => ...) expression. The decision to expose an operation as a command becomes roughly "one line plus a closure" instead of "a day of boilerplate," which changes the economics of shipping operational tooling at all.
• Feature scoping: CLI-first vs. UI-first. When a roadmap item is still unvalidated ("should ops be able to re-run this import?"), the cheap move is a Silly command behind the existing service layer, measured for a sprint, and only then promoted to a full UI or public API. This is a de-risking lever for roadmap bets, not just a tooling convenience.
• Architecture standard: thin command, thick service. Commands resolve parameters by name and by type-hint from any PSR-11 container, so the CLI layer stays a pure adapter over domain services you already own. That's a reviewable written standard rather than an implicit convention — commands must not contain business logic.
• Platform decisions outside the Laravel runtime. Silly extends Symfony\Console\Application, so commands run without booting Laravel (avoiding the ~100ms+ framework boot for a script that takes 20ms of real work). This supports the decision to ship runbook/ops CLIs, migration runners, and CI helpers as standalone Composer binaries in repos that are not Laravel apps — including polyrepo fleets where dragging a Laravel skeleton in would be indefensible.
• Package/tooling distribution decisions. Proven in production by Bref, Laravel Valet, Blacksmith, and Documentarian as a bin/ substrate. If the roadmap includes publishing a library or OSS tool that needs a console entry point, adopting Silly is a decision to ship a binary without forcing a framework dependency on your consumers.
• Team skill reuse. The same pattern and muscle memory travel across services and languages-adjacent ecosystems; you don't retrain engineers per repository.

When to Consider This Package

Consider adopting it when:

• You need a console entry point in a repository that is not a Laravel application, or where framework boot cost is disproportionate to the command's actual work.
• Your team already thinks in Symfony Console terms. Silly is a superset — $input, $output, SymfonyStyle, setDefaultCommand(), and the whole Symfony Console ecosystem remain available with zero migration path, so the escape hatch is real.
• You want dependency injection inside closures rather than a class per command. This is the genuine differentiator; vanilla Symfony Console pushes you toward command classes or manual container plumbing. PHP-DI and Pimple editions ship in-tree, and any PSR-11 container works.
• You're distributing a Composer-installed tool and need a small, MIT-licensed, framework-agnostic substrate for its bin/.
• You need scriptable commands fast: the string signature syntax ([name], [--yell], [--age=], --option=*, hyphen-to-camelCase mapping, defaults inferred from closure parameters) is the lowest-friction argument definition available in PHP.

Look elsewhere when:

• You are building inside Laravel and the command belongs to the app. Laravel's Artisan is already there, already wired to the container, already has scheduling, output helpers, and interactive prompts. Adding Silly alongside Artisan means two command registries and two mental models for the same job — a governance cost with no payoff. Prefer Artisan unless the command must run without the app.
• The CLI is becoming a product in its own right. If you need config file loading, environment bootstrapping, rich TTY components, or a plugin system, evaluate Laravel Zero or a fuller Symfony Console setup; you will otherwise rebuild those pieces ad hoc on top of Silly.
• You need long-term vendor assurance. Silly is effectively a small, single-maintainer-adjacent project (~933 stars, community PRs for Symfony 6/7/8 compatibility, MIT). It is actively maintained with releases tracking Symfony, but if your organization requires a support contract, SLAs, or a large contributor base, price in Tidelift or budget the (small) cost of forking/vendoring.
• Your team has no Symfony experience. The docs are good but assume Console familiarity; "read the Symfony docs" is the stated answer for advanced behavior. Untrained teams will hit argument-mode, exit-code, and interactivity edge cases.

Adoption checklist before committing:

1. Pin a version and confirm it supports your Symfony Console major (1.10.x covers through Symfony 8).
2. Standardize on one DI strategy (PSR-11 via PHP-DI is the sane default) — don't let two container styles coexist.
3. Write down the rule that commands are adapters only; enforce it in review.
4. Require exit codes to be returned explicitly — historical releases patched exit-code propagation, so make tests cover it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can cut the cost of internal operational tooling from project-shaped to task-shaped. Silly is a small, MIT-licensed, actively maintained library that lets engineers define a working command-line tool in a single line over services we already have, without standing up or booting a full application. That means faster validation of roadmap ideas (ship the CLI first, build the UI only if usage earns it), lower infrastructure cost for scripts that don't need a framework, and no new licensing spend. It's proven in widely used tools including Bref and Laravel Valet, and the risk is contained: it's ~900 stars, small enough to vendor, and a two-day swap to plain Symfony Console if we ever outgrow it.

For engineering (the ask): Standardize on Silly for standalone console binaries — repos that are not Laravel apps, distributed Composer tools, ops/migration/CI scripts — and explicitly not for commands inside the Laravel app, which stay in Artisan. Rationale: one-line command definitions, DI inside closures via any PSR-11 container, full Symfony Console compatibility (so $input, $output, SymfonyStyle, and setDefaultCommand() remain available), and no framework boot on the hot path. Two rules come with it: commands are thin adapters over services, never containers of business logic, and every command returns an explicit exit code with test coverage. If the tool grows config loading, plugin support, or rich TTY interaction, we graduate to Laravel Zero or full Symfony Console — a small, well-understood migration because the container and command signatures carry over.