- What does samasend/laravel-make-scope actually do?
- It is a developer-time code generator, not a runtime library. It adds a single Artisan command, make:scope, that scaffolds reusable Eloquent local-scope boilerplate and wires the generated scope into your models. There is no facade, no config file, and no service binding used at request time, so it cannot affect request latency or data integrity.
- How do I install samasend/laravel-make-scope?
- Install it with Composer as a dev dependency: composer require --dev samasend/laravel-make-scope. The package supports Laravel package auto-discovery, so the make:scope command should appear in php artisan list without any manual provider registration. Before adopting it, test the install in a scratch app pinned to your production framework version.
- Which Laravel and PHP versions does this package support?
- The last release was July 2021, which places its illuminate/console and PHP constraints in the Laravel 8 era. Installing it against Laravel 10, 11, or 12 will likely fail Composer's constraint solver, and forcing it in with --ignore-platform-reqs may leave the command signature or stub out of step with current conventions. Verify resolution against your pinned framework version before proposing it to your team.
- What does the make:scope command generate?
- It scaffolds the boilerplate for an Eloquent local scope and adds the wiring so the scope is available on your model, keeping query logic out of controllers and scattered model methods. Because the output is plain PHP committed into your repository, it is worth checking whether the generated pattern matches your existing scope conventions or introduces a second style in the codebase.
- Do I need to register the service provider in config/app.php?
- No. The package ships with extra.laravel.providers metadata, so Laravel's auto-discovery registers the provider and exposes the make:scope command automatically. There is no configuration surface to publish or tune, which keeps the integration footprint minimal.
- Can I publish and customize the stubs?
- The package's value is the command class plus its stub, so if you want to own and evolve the template without touching vendor code, the cleanest route is to copy the command class and stub into app/Console/Commands under your own namespace. That removes the abandoned dependency entirely while preserving the ergonomics of the generator. Confirm whether stubs are publishable in your installed version before deciding.
- Should it be a production dependency or a dev dependency?
- It is a code generator, so it belongs in require-dev and should be excluded from production autoload. Pinning an exact version and committing the lockfile limits the risk of a surprise transitive update. The generated scope code itself has no runtime dependency on the package.
- Is the package actively maintained and safe to adopt?
- The repository is archived, has a single maintainer, roughly 101 stars, no release in four years, and no security-response channel, and the command is likely untested. Runtime risk is low because nothing executes in production, but lifecycle risk is high. Treat any adoption as a short-horizon, pinned decision rather than a multi-year commitment.
- What happens to my generated scopes if I stop using the package?
- Nothing breaks. The scopes are plain PHP written into your application, so the artifact outlives the tool; if the package disappears tomorrow, every generated scope keeps working. You would simply write subsequent scope methods by hand or fork the generator into your own codebase.
- Are there alternatives to this package?
- On Laravel 12 and later, the framework-native #[Scope] attribute removes most of the boilerplate this package exists to generate, which makes it the strongest long-term choice if your version allows it. Otherwise you can vendor the single command class and stub into your app, or write local scope methods by hand and enforce naming through code review.