- How do I install getsolaris/laravel-make-service?
- Install it with Composer, preferably as a dev dependency since it is scaffolding tooling rather than a runtime library: composer require --dev getsolaris/laravel-make-service. The package does not require service provider bootstrapping, migrations, or a config file, so there is nothing else to register. Once installed, the make:service Artisan command becomes available immediately. Keeping it in require-dev keeps it out of your production dependency surface entirely.
- Which Laravel versions does this package support?
- The package targets Laravel 5 and up, and the latest release (v1.1.4) advertises compatibility with the Laravel 13.x line. Because that release is a compatibility-only patch, always confirm the exact constraint string in its composer.json before adopting it. A loose constraint such as ^10|^11|^12|^13 is safe for upgrades, while a hard pin to a recent minor is a warning sign. Also check that the package's PHP floor is at or below your runtime so you are not forced into an early PHP bump.
- How do I generate a service class with the make:service command?
- Run php artisan make:service YourServiceName from your project root and the package writes a new service class into your application based on its bundled stub. You then fill in the business logic, dependency injection, and any interface binding yourself in the generated file. The generator only scaffolds the class shell; it does not register the class in a service provider or wire up container bindings for you. That means the generated file is ordinary application code you own, review, and commit like any other.
- Can I customize the service class stub template?
- Yes. The package ships publishable stubs, so you can publish them and commit the customized versions to your repository. That lets you encode house conventions such as strict types, final or readonly modifiers, namespace depth, and constructor injection style so every scaffold matches your existing service layer. Publishing and committing the stub is the step that gives durable value, because otherwise you inherit the package default on every new class. Treat the customized stub as a template your team reviews whenever conventions change.
- Does make:service support nested namespaces for subdirectories?
- Nested namespace or subdirectory generation, for example make:service Billing/InvoiceService, is worth verifying with a quick test run rather than assuming. If it is supported, the generated class should land in the matching subdirectory with the correct namespace, which is what you need for a modular structure. The fastest check is to run the command in a scratch directory and diff the output against two or three of your hand-written service classes. If nested paths are not supported, you can adapt the published stub or simply move the file and fix the namespace manually.
- Should laravel-make-service be a production or dev dependency?
- Use it as a dev dependency. It contributes an Artisan generator plus stubs, not runtime code, so it adds zero surface area to your production request lifecycle and should not be loaded in production. The generated service classes themselves are normal application code that you commit and deploy, and those are what run in production. A defect in the generator can only produce a bad scaffold, which code review catches before it merges.
- When should I use a service class instead of putting logic in a controller?
- The package supports the MVCS pattern, where business logic lives in dedicated service classes rather than controllers or models. Reach for a service when an operation spans multiple models, calls external systems, or needs to be reused from a controller, a queued job, and an Artisan command. Keeping that logic in a service makes it easier to unit test in isolation and keeps controllers thin. The generator just removes the boilerplate of creating the file; the decision about boundaries is still a design choice your team makes.
- Will this package conflict with my existing service container bindings?
- The package only scaffolds class files and does not assume or enforce a binding convention, so it should not conflict with your existing provider registrations. You remain responsible for binding interfaces to implementations in your own service providers if your conventions require it. If your house style uses interface-first services, customize the published stub to emit the contract and let your provider handle the wiring. Validate this against one real module before rolling it out broadly.
- Is getsolaris/laravel-make-service actively maintained?
- It is a single-maintainer package, and recent compatibility updates appear to arrive through automated Laravel Shift pull requests rather than active feature development. The v1.1.4 compatibility-only release is a positive signal that the maintainer merges framework updates, but it also suggests the package is on life support. The practical risk is that if Shift PRs stop being merged, you end up pinning a framework version or forking. Because it is dev-only and the output is code you own, that risk is contained rather than a production outage risk.
- What are the alternatives to this package for generating services in Laravel?
- You can achieve the same result by adding a custom Artisan command and a stub file to your own application, which removes the third-party dependency entirely and gives you full control over the template. Many teams simply run make:class or create the file manually and rely on a code snippet or IDE template. The advantage of this package is that it is ready-made and small; the advantage of an in-house command is that it can encode your conventions exactly and never goes unmaintained. Either way, publish and commit the stub so scaffolding stays consistent.