Laravel Make Scope Laravel Package

Technical Evaluation

Architecture fit. samasend/laravel-make-scope is a developer-time code generator, not a runtime library. It contributes a single Artisan command (make:scope) that scaffolds Eloquent local-scope boilerplate; there is no facade, no config surface, no service binding consumed at request time, and no database or queue interaction. That is the most favorable architectural profile a third-party Laravel package can have: it sits in require-dev, is excluded from production autoload, and cannot affect request latency, error rates, or data integrity. Fit with a standard Laravel codebase is essentially unconstrained.

Integration feasibility. High on paper — Composer install, Laravel package auto-discovery via extra.laravel.providers, command appears, command runs. The real constraint is staleness: the last release is July 2021, which places the illuminate/console and PHP constraints in the Laravel 8 era. Installing it against Laravel 10/11/12 will likely fail Composer's constraint solver, and even if --ignore-platform-reqs or a constraint override forces it in, the command signature and stub may not match current Laravel conventions. Feasibility must be proven in a scratch app pinned to the production framework version before any proposal.

Technical risk. Low runtime risk, high lifecycle risk. The composite score of 0.4525 reflects what the metadata already says plainly: archived, single maintainer, 101 stars, no release in four years, no security-response channel. The mitigating factor is unusually strong — the package's output is plain PHP committed into the repository, so the artifact outlives the tool. If the package disappears tomorrow, every generated scope keeps working; you simply write subsequent scope methods by hand or fork the generator. Blast radius is measured in developer minutes, not incidents. The one directional threat worth flagging: Laravel 12 introduced the framework-native #[Scope] attribute, which removes the boilerplate this package exists to generate. A generator whose raison d'être is being absorbed upstream should not be adopted with a multi-year horizon.

Key questions.

• Which Laravel and PHP versions are declared in composer.json, and does it install cleanly against our pinned framework version?
• Does it generate a class, a trait, or a model method stub — and therefore does the output match our existing scope conventions or introduce a second pattern?
• Is registration via auto-discovery or manual config/app.php entry?
• Are stubs publishable, so we can own and evolve the template without touching vendor code?
• Is there any test suite, or is the command untested (typical for packages of this size)?
• Has the maintainer stated an archival reason (superseded, abandoned, merged upstream)?

Integration Approach

Stack fit. Appropriate for any Eloquent-centric Laravel application, with the highest value where models are numerous and scope methods are written ad hoc by many contributors — the generator enforces naming and file placement. Lower value in small codebases where the boilerplate saved is a few lines per month.

Migration path. Two options, and the decision should be made explicitly rather than by default:

1. Dev dependency — composer require --dev samasend/laravel-make-scope, pinned to an exact version, lockfile committed. Acceptable only if the version spike against our framework version passes cleanly.
2. Vendor the command — copy the single command class and stub into app/Console/Commands/ under our namespace. Cost is a few hours of engineering and removes the abandoned dependency entirely while preserving the ergonomics. Given the archival status, this is the recommended default for any team that intends to use the workflow beyond a single quarter.

A third path — adopt the framework-native #[Scope] attribute on Laravel 12+ and skip the package — is the strongest long-term answer if our framework version allows it.

Compatibility. Verify three things in a disposable app: Composer resolution against our pinned Laravel/PHP, command registration under auto-discovery, and generated output style versus our existing scopeX methods. Treat any Composer conflict as a hard stop on option 1, not something to force with constraint overrides — an unmaintained generator that only installs by coercion is a support liability with no upside.

Sequencing.

1. Version spike in a throwaway app matching production (half a day).
2. Decide: dev dependency, vendored fork, or framework-native attribute.
3. If adopting, pilot on two or three models and codify the naming convention in the team's engineering standard before broad use.
4. Record the decision and its rationale in the architecture log, including the archival status, so a future maintainer does not rediscover it.

Operational Impact

Maintenance. Upstream maintenance is zero and should be assumed to stay zero. The package will not receive PHP or Laravel compatibility patches. Internal ownership is therefore mandatory: one named owner for the vendored command or the pinned dependency, with the expectation of a small amount of work at each major Laravel upgrade. The code volume is small enough that this is a recurring hour, not a recurring project.

Support. Effectively nil. 101 stars implies a small user base, so community answers will be scarce and the maintainer is unlikely to respond to an archived repository. Any blocker is ours to solve. This is tolerable precisely because the failure mode is "the generator stops working," not "the application stops working."

Scaling. No runtime scaling concerns whatsoever — no queries, no memory, no configuration, no per-request cost. Operationally it scales with team size in a beneficial direction: a shared generator reduces stylistic drift in query logic across models and contributors.

Failure modes.

• Composer constraint conflict on the next Laravel upgrade — most probable failure, resolved by vendoring or removal.
• Silent auto-discovery breakage after a framework upgrade — command simply stops appearing; low severity, obvious to the user.
• Stub drift — generated code diverges from current Laravel idioms, quietly producing legacy-style scopes.
• Pattern duplication — if the generated style differs from existing hand-written scopes, the codebase ends up with two conventions, which is worse than either alone.
• Supersession — the framework-native #[Scope] attribute makes the tool redundant on modern versions; teams should not standardize on it in a way that requires a later migration.

Ramp-up. Near zero. Any Laravel developer understands php artisan make:*; the command is self-documenting. Onboarding cost is a line in the team README, not a training session. The genuine ramp-up risk is institutional rather than individual: a future maintainer inheriting an abandoned dependency without the context recorded in the architecture log.

Bottom line. Low-risk, low-value convenience tool with a closed upstream. Adopt only as a dev-time dependency if it installs cleanly against our framework version, or vendor the command if the workflow is worth keeping. Do not treat it as a strategic dependency, and prefer the framework's native scope attribute where available.