- How do I install flipbox/lumen-generator in a Lumen project?
- Install it as a dev dependency with composer require --dev flipbox/lumen-generator. Lumen does not support package auto-discovery, so you must manually register Flipbox\LumenGenerator\LumenGeneratorServiceProvider::class in bootstrap/app.php. After that, the make:* commands and route:list are available from the Artisan CLI. No configuration file, credentials, or external services are required.
- Which Artisan commands does this package add to Lumen?
- It restores Laravel's scaffolding generators such as make:controller, make:model, make:migration, make:seeder, and make:middleware, plus convenience commands like route:list and package discovery. The exact set depends on which Illuminate console components Lumen ships with by default. Some generators tied to optional components like events, queues, validation, broadcasting, or policies may be unavailable or may produce classes you need to support with additional illuminate/* packages.
- Does flipbox/lumen-generator work with Laravel, or only Lumen?
- It targets Lumen specifically, because Lumen deliberately strips the make:* Artisan commands from the framework and this package re-registers them. If you are on full Laravel, you do not need it at all since Laravel ships these generators natively. The package is essentially a bridge that gives Lumen the same scaffolding workflow Laravel developers already know.
- Should I require it as a dev dependency or in production?
- Always declare it with require-dev. The package operates entirely at build and scaffold time, touches no request path, and adds no middleware, routes, or runtime bindings beyond the service provider registration. Installing it in production would only bloat the deployed artifact with console classes and stubs for no benefit. Keeping it dev-only also keeps your production image composition clean.
- Can I customize the generated stubs for my team's conventions?
- Yes. The package's stubs are publishable and overridable, which is the main customization lever for teams that want house namespaces, base classes, or company boilerplate. Publishing the stubs lets you enforce conventions consistently across generated controllers, models, and migrations. Decide early who owns those published stubs so they stay in sync with framework upgrades.
- Which Lumen versions are supported, and could a Lumen upgrade break the generators?
- The generators subclass Illuminate console commands and reference framework internals, so a Lumen major upgrade can silently break individual commands even when the service provider still boots. Pin the package version explicitly in composer.json and test your most-used commands after every Lumen bump. Last release was April 2024, so treat upgrade compatibility as something you verify rather than assume.
- Is flipbox/lumen-generator safe to run in production environments?
- There is no runtime risk because the package never executes on the request path; its blast radius is confined to developer machines and CI images. The real concern is artifact hygiene, not security. Keep it out of production by declaring it under require-dev and verifying your build pipeline does not install dev dependencies in the release image.
- How do I see the registered routes in a Lumen app?
- The package adds route:list, which prints your registered routes from the Artisan CLI in the familiar Laravel format. That is useful in Lumen because route debugging is otherwise awkward without the full framework. Make sure the provider is registered in bootstrap/app.php before running the command.
- What are the alternatives if I want Laravel-style generators in Lumen?
- You can hand-write classes, copy stubs into your project, or maintain your own console commands, but that reintroduces the friction this package removes. The more strategic alternative is migrating from Lumen to Laravel, at which point you uninstall this package because the generators ship natively. Adoption here is best framed as a de-risking bridge toward that migration rather than a permanent fixture.
- Is this package actively maintained, and should I be worried about its low adoption?
- The project is MIT-licensed with a release in April 2024, but it has few recorded dependents and looks to be in maintenance mode tracking a framework that is itself de-emphasized. None of that is a runtime problem, but it does mean you should pin versions and be prepared to fork or inline the stubs if a command breaks. The larger question is whether your team is on Lumen by deliberate constraint or by inertia, since that determines whether this package is a bridge or a dead end.