Product Decisions This Supports
- Developer Experience (DevEx) roadmap line item. v3.0.1 adds an explicit convention — always prefer existing
php artisan commands (notably make:*) when generating files — which is the kind of change that belongs to a "standardize how code gets written" workstream rather than a feature workstream. It gives you a citable, maintainer-blessed policy to point at instead of authoring an internal style guide from scratch.
- Build vs. buy for scaffolding standards. Instead of a PM/Eng org writing and maintaining its own "how to create a controller/model/migration/job" doc, this package carries that decision upstream. Adoption cost is near-zero on a patch release; the alternative (internal scripts + a wiki page that rots) carries an ongoing maintenance owner.
- AI-assisted development governance. Guidance of this shape is typically consumed by coding agents and IDE assistants as rule/context files. If your roadmap includes Copilot/Cursor/agent workflows, this is a cheap lever to make generated code land on framework idioms (
artisan make:*) rather than hand-rolled boilerplate — fewer divergent file structures, smaller review diffs, less "agent invented a folder" churn.
- Onboarding and contractor ramp-up. A one-line principle like this compresses the "how do I add a thing here?" question for new hires and external teams into a single rule that maps to framework documentation they can already find.
- Code review hygiene / definition-of-done. Gives reviewers an objective, non-personal basis to push back on hand-written scaffolding ("the project standard is artisan-first"), reducing nitpick cycles and reviewer-dependent variance.
- Prioritization signal for platform investment. The fact that this shipped as a documented principle rather than a lint rule or generator hook tells you where the maintainers draw the line: guidance, not enforcement. That should shape whether you fund an internal CI gate on top.
When to Consider This Package
Consider it when:
- You run multiple Laravel teams or a rotating contractor bench and want one shared default for how files come into existence.
- You are standardizing project skeletons across services and want generated code to match framework conventions by default.
- You have AI coding assistants in the loop and want them steered toward first-party generators instead of ad-hoc file creation.
- You want a low-commitment, additive dependency — v3.0.1 is a patch with a purely additive convention; no migration, no config rewrite, no behavior change to roll back.
- Your team is on a currently supported Laravel/PHP version and already uses artisan generators in normal practice (i.e., the principle describes what you mostly do already, so adoption is codifying reality).
Look elsewhere or deprioritize when:
- You need enforcement, not documentation. This release does not describe a CI check, linter rule, or generator override — for hard gates the relevant tools are static analysis and formatters (PHPStan/Larastan, Pint, PHP-CS-Fixer) plus custom CI steps. Do not buy this expecting compliance guarantees.
- You need runtime behavior: routing, queue, auth, observability. A convention release does not move that needle.
- You are on a legacy or non-Laravel PHP codebase, where
artisan make:* does not map to your file layout.
- Your team is single-team, low-churn, and already consistent — the marginal value of codified convention is small relative to the review overhead of adding a dependency.
- You are pinned to an older major line: v3.x implies a major-version boundary; confirm upgrade cost from your current pin before treating this patch as free.
How to Pitch It (Stakeholders)
To executives (one paragraph): This is a small, low-risk patch to a package we use to keep Laravel codebases consistent. It adds one documented rule — use the framework's own artisan generators when they exist — which is the cheapest possible way to reduce onboarding time, review churn, and inconsistency across teams and contractors. There is no migration, no runtime change, and no new operational surface. The strategic value is that it gives us an externally maintained standard to point at rather than one we author and maintain ourselves, and it aligns with how AI coding assistants generate code for us. Recommend adopting as a stated team standard; do not fund extra tooling on the back of it.
To engineering leads: Treat v3.0.1 as documentation-level guidance, not an enforcement mechanism. It formalizes artisan-first file creation (make:model, make:controller, make:job, etc.), which aligns generators with framework conventions and keeps diffs small and predictable — particularly relevant where agents or newer engineers are authoring files. It complements Pint/PHPStan rather than replacing them: if you want this to be a real gate, that is our work to do (CI check, PR template line, or a code-owner note), and it should be scoped as an internal task. Upgrade path is a standard patch bump; confirm your pinned major version supports v3.x before merging, and expect zero code changes.
To the wider org / stakeholders affected: Practically, reviewers can now cite a shared rule instead of personal preference, and new joiners get one clear answer to "how do I add a file here?" The change is additive and reversible; the main cost is a small amount of change management to make the convention visible (README or contributing guide callout) so it is actually followed rather than merely installed.