Product Decisions This Supports
- Standardizing team and tooling conventions without owning them ourselves. v3.0.1 adds a stated principle — always prefer
php artisan commands when they exist (e.g. make:*) over hand-creating files — which is exactly the kind of opinionated default a PM wants codified once and inherited everywhere, rather than re-litigated in every code review or prompt.
- Build vs. buy on internal "how we do Laravel" guidance. If this package is adopted, the rule set becomes a maintained external dependency instead of an internal wiki page that rots. That shifts a recurring docs-maintenance cost into a versioned upgrade line item.
- Scaffolding consistency as a measurable quality lever. Generated file placement, naming, and boilerplate become deterministic. This is directly relevant to onboarding time, review cycle time, and defect classes caused by mis-placed or hand-rolled classes (wrong namespace, missing registration, drifted stubs).
- Agent/automation readiness. A rule phrased as an imperative ("always use artisan when it exists") is machine-consumable. This supports roadmap items around AI-assisted development, code generation guardrails, and CI checks that enforce conventions rather than merely documenting them.
- Low-risk adoption decision. v3.0.1 is a patch adding guidance, not machinery — no API surface change, no migration. This is a "merge and move on" class of change, not a decision that consumes roadmap capacity.
When to Consider This Package
Consider it when:
- Your team is Laravel-standardized and you want a single source of truth for conventions that is versioned and upgradable, rather than an internal document owned by whoever last touched it.
- You are onboarding engineers (or coding agents) into a Laravel codebase and want the "correct" path to be the default path — hand-created files are a common source of structural drift.
- You already have, or plan to have, automated enforcement (lint rules, CI checks, prompt/rule files for assistants) and need a canonical rule set to feed it.
- You are comfortable with a package that expresses opinions. Convention packages only pay off if the team actually follows them.
Look elsewhere or defer when:
- Your codebase deliberately diverges from Laravel defaults (custom directory structures, non-standard namespaces). A rule that mandates
make:* output will fight your architecture rather than support it.
- You need guarantees, not guidance. This release is documentation-shaped — it changes what is recommended, not what is enforced. If you need hard enforcement, budget separately for the tooling that checks compliance.
- You cannot absorb the ongoing cost of tracking upstream opinion changes. Note that this is a v3.x line; a patch-level convention addition implies the major version already reorganized the rule set. Confirm the v3 upgrade path and churn rate before committing.
- You are evaluating this as a runtime dependency. Nothing here suggests runtime behavior; judge it as a process/tooling dependency.
Open questions worth resolving before adoption: Is the guidance English-only in the source but surfaced in Norwegian here, and does that matter for a multi-region team? Is there a compliance-checking companion, or is adoption purely honor-system? What changed in the v3.0.0 major that this patches?
How to Pitch It (Stakeholders)
For executives: This is a small, low-risk dependency that encodes "how we build Laravel" as a versioned artifact instead of tribal knowledge. The latest patch adds one rule — prefer framework generators (artisan make:*) over manual file creation. The business value is consistency: fewer structural mistakes, faster onboarding, less review time spent on convention debates. Cost is a patch upgrade and a small ongoing obligation to track upstream changes. No migration, no runtime risk.
For engineering: v3.0.1 adds a stated convention: always use php artisan commands where they exist, particularly make:* for new files, rather than creating them by hand. Treat the package as the canonical source of Laravel conventions and align local practice and any agent/CI rule files to it. Because this is guidance rather than enforcement, expect to pair it with actual checks if you want compliance. Flag any intentional deviations from Laravel defaults before we adopt, since this rule assumes a conventional structure.
Recommendation: Adopt the patch, but validate two things first — that our project layout is close enough to Laravel defaults that make:* output lands where we want it, and what the v3.0.0 major changed. If both are clean, this is a routine upgrade with no roadmap impact.