Laravel Make Scope Laravel Package

Product Decisions This Supports

• Query-layer architecture: Backs a deliberate move from "fat models" and ad-hoc scopeXxx methods toward composable, single-responsibility query objects. Every generated scope class is a named, testable unit of business logic (ActiveSubscriptionScope, WithinSLAWindowScope), which is a prerequisite for domain modules, package extraction, or a future read-model/CQRS boundary.
• Team velocity and code consistency: A generator plus publishable stubs converts an internal convention ("we write scopes this way") into an enforced artifact. This is the cheapest possible lever for standardizing code across squads — no code review cycles lost to boilerplate shape, no style drift between teams.
• Roadmap enabler for legacy refactors: Gives a low-friction, incremental path to carve tangled Eloquent queries out of controllers/repositories. Scopes can be migrated one at a time without a big-bang rewrite, which de-risks a "clean up the data access layer" roadmap item.
• Build vs. buy call: This is a convenience purchase, not a strategic dependency. Functionally it is one Artisan command plus stub files — roughly half a day of internal engineering. The decision is therefore mostly about maintenance ownership, not capability: adopt only if you are comfortable pinning or forking.
• Ecosystem-fit signal: Useful test case for a broader policy question — does the team allow archived/abandoned dev-tooling dependencies? Whatever you decide here sets precedent for the next 20 similar asks.

When to Consider This Package

Consider it when:

• You have already committed (or are committing) to the invokable/query-object scope pattern and want a generator so juniors don't hand-roll inconsistent versions.
• Your codebase is large enough that dozens of scopes exist across models, and naming/structure drift is a real review cost.
• You are on an older Laravel version that matched its 2021 support matrix, or you are willing to vendor the stubs into your own app and treat the package as reference material.
• You install it as a require-dev dependency only — it is developer tooling, never runtime code, so blast radius on production is near zero.

Look elsewhere or build in-house when:

• Maintenance status is disqualifying: archived, no release since July 2021, 101 stars. There is no committed support for Laravel 10/11/12, no security response path, and no CI guarantees against current framework versions. A Composer constraint conflict during a framework upgrade is the most likely failure mode, and it will surface at the worst time.
• Plain local scopes (public function scopeActive($q)) or a small internal make:scope command cover 90% of the value with zero dependency risk — which is most teams.
• You need more than generation: query-builder ergonomics, filtering from request parameters, or nested scope composition are better served by actively maintained query-builder packages.
• Your org forbids abandoned dependencies outright (common in regulated environments) — in that case, copy the stub, credit the MIT license, and move on rather than adding a dependency.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free, MIT-licensed developer tool that standardizes how our engineers write database queries. It costs nothing, touches no production code, and removes repetitive boilerplate so query logic stays consistent and reviewable across teams. The caveat is that the project is no longer maintained. So the recommendation is not "adopt this package" — it's "adopt this pattern," using the package's stubs as a template owned internally. Net cost: under a day of engineering. Net benefit: a durable internal convention instead of 30 competing ones.

For engineering leadership: Treat it as a template, not a dependency. Vendor the command and stubs into our own tooling repo under MIT attribution, add it to our lint/CI expectations, and we get the standardization benefit with no supply-chain or upgrade risk. If we do install it, it goes in require-dev, pinned, with a documented owner and a sunset trigger (the next Laravel major upgrade). Do not let it become load-bearing runtime infrastructure.

For the engineering team: One command generates a named, testable scope class; stubs are publishable so we control the shape. Use it to pay down query sprawl incrementally — one scope per PR, no big-bang refactor. Rule: scopes contain query intent only, no side effects, no business orchestration, and each ships with a test.