Console Laravel Package

Getting Started

• Install with composer require webman/console, then run php webman (Windows) or ./webman from the project root. The plugin exports a webman bootstrap file into the project root; that file is your entry point for every command.
• Verify the plugin is enabled in config/plugin/webman/console/app.php, and note that custom commands are registered in the app-level config/command.php. Those are the two config files you will touch most.
• First use case: scaffold a feature end-to-end. php webman make:controller User, php webman make:model User, php webman make:middleware Auth, then php webman route:list to confirm the routes registered the way you expect. This is the fastest way to learn the package's conventions because the generated stubs show you the expected namespaces and directory layout.
• Where to look first: php webman list and php webman help <command> for signatures and options, then vendor/webman/console/src/Command/ to read the actual generator source. The source is small and is the authoritative reference for what each make:* command writes.

Implementation Patterns

• Scaffolding loop. Use make:controller, make:model, make:middleware, make:command, make:bootstrap, and make:exception as the starting point for new files, then immediately edit the stub. Treat generated code as a skeleton, not production code.
• Custom commands. Create app/command/ReportCommand.php extending Symfony\Component\Console\Command\Command, implement configure() and execute(), and add the class to config/command.php. Keep execute() thin: parse input, call a service class, write output. That way the same logic is callable from a controller or a queued job.
• Plugin authoring loop. php webman plugin:create vendor/name scaffolds under plugin/vendor/name. Develop there, run php webman plugin:export vendor/name to sync into vendor/, test, and use plugin:install / plugin:uninstall against a clean project to validate the install experience your users will get.
• Ops and cron work. Console commands are the right home for one-off jobs, data migrations, cache warmups, and deployment tasks. Pair them with Timer for in-process scheduling, but keep anything you might want to run manually as a console command.
• Symfony reuse. Because commands are standard Symfony Console commands, lean on Table, ProgressBar, QuestionHelper, and -v/-vv/-vvv verbosity rather than hand-rolling output formatting.
• CI integration. Return Command::SUCCESS / Command::FAILURE and let the shell exit code drive your pipeline. Add a --dry-run option to any command that mutates data so it can be exercised safely in CI.

Gotchas and Tips

• Missing webman file. The root webman executable is exported by the plugin installer, not reliably created by Composer in every setup. If php webman fails with "could not open input file," reinstall the plugin or copy the file from the package. On Windows always invoke php webman; the shebang/executable bit is irrelevant there.
• Command not appearing in list. Registration in config/command.php is the source of truth. Adding a class to app/command alone may not register it depending on version. Re-run php webman list after any config change; if config is cached, clear it.
• Autoload failures after make:*. Generated namespaces assume app\ maps to app/ in composer.json. If a new class is "not found," run composer dump-autoload before debugging anything else.
• Stubs don't know your conventions. Generated controllers won't match your base controller, response helpers, or validation style. Keep a small set of hand-tuned templates or a post-generation cleanup step if you scaffold often.
• Destructive plugin commands. plugin:uninstall removes files and plugin config; plugin:export overwrites files under vendor/. Commit or back up config/plugin/... before running either.
• No shared state with the web process. A console command runs in its own process. Do not assume Gateway, request context, or warm in-memory caches exist. Bootstrap your own DB/Redis connections inside execute().
• Exit codes and streams. Returning a non-int from execute() throws on newer Symfony versions. Write normal output to stdout and errors to ConsoleOutputInterface::getErrorOutput() so shell pipelines and log scrapers behave.
• Debugging. Use php webman <command> -vvv for verbosity. If a command dies silently, check runtime/logs — the console bootstraps the framework, so framework-level exceptions land there rather than in your terminal.
• Extension point. Never edit files under vendor/webman/console. Instead register your own command class; if you need to replace a built-in, register a class with the same name and confirm precedence with php webman list.