Generelle Laravel Prinsipper Laravel Package

Getting Started

v3.0.1 is a guidelines/content release — no runtime code, config keys, or public API changed, so upgrading from any v3.x is a drop-in composer update. Treat this package as a conventions source of truth rather than a library you call at runtime.

Order of work when adopting it:

1. composer require --dev <vendor>/< package> and commit the lockfile diff (v3.0.1 only touches the guideline text, so the diff should be documentation-sized — if you see PHP changes, you're looking at the wrong tag).
2. Locate the guidelines entry point in vendor/<vendor>/<package>/ — typically a root README/AGENTS.md-style file plus a guidelines/ or rules/ directory split by topic. Read the file order top-down; sections are additive rules, not tiers.
3. Publish anything publishable (php artisan vendor:publish --tag=<package>-config / -stubs) so your team can amend rules without forking.
4. First use case: point your AI coding agent (or the reviewer's PR checklist) at the published guidelines file, then run one real task — scaffold a model + migration + factory + controller for a small feature — and confirm the agent/developer actually reaches for php artisan make:* instead of hand-writing files. That single task exercises the new v3.0.1 rule end to end.

Implementation Patterns

Wire the guideline into the tools that already gate merges. A prose rule with no enforcement surface decays within a sprint.

• Agent context: reference the published guideline file from your repo's own agent instruction file (or .cursor/rules, CLAUDE.md, equivalent) so the rule set is loaded automatically instead of pasted per session.
• PR template: add a one-line checkbox — "New classes/migrations/factories/tests created via artisan make:*" — plus a reviewer note that hand-authored scaffolding is a nit, not a blocker.
• CI: a cheap grep job that fails on new hand-created files in conventional locations (e.g. a new database/migrations/*.php without the artisan-generated header shape) catches the drift that review misses.

Standardise the exact invocations your project uses. Bake the flags into a team cheat sheet, because the rule only pays off when people use the same shapes:

php artisan make:model Invoice -mfs      # model + migration + factory + seeder
php artisan make:controller InvoiceController --resource --model=Invoice
php artisan make:test InvoiceTest --pest
php artisan make:livewire CreateInvoice  # or make:filament-*, make:action, etc.

Pair with custom stubs. If the package ships publishable stubs, publish them and adjust namespace/declare(strict_types=1)/final-class conventions. That's how "always use make:*" and "our house style" stop fighting each other — the generator produces compliant files, so nobody hand-edits to fix the header.

Sequence it with the rest of the toolchain. Generated files should be the input to Pint, PHPStan/Larastan, and Rector, not an exception to them. Run pint after generation in your local workflow (or a composer make-* script wrapper) so a fresh scaffold is already formatted and doesn't pollute the next diff.

Use it as onboarding and review vocabulary. For new hires, the guideline doubles as "how we write Laravel here" — the artisan rule in particular teaches discovery of generators (make:observer, make:policy, make:cast) that juniors often don't know exist.

Gotchas and Tips

• This is a documentation-only bump. v3.0.1 adds one principle: always prefer php artisan commands when one exists (e.g. make:* for new files). Nothing is enforced by the package at runtime — no service provider, no command, no lint. If you expected a behaviour change, you need your own CI/review hook.
• The source text is Norwegian. Don't paste it verbatim into an English-language agent context and assume it lands; either keep it monolingual by team convention or maintain a translated copy alongside. Translated copies drift — keep one canonical file and generate the other.
• php artisan must be able to boot. In package-development repos, make:* against the host app can fail if the provider isn't registered or the app is on a broken config cache. php artisan optimize:clear first; this is the most common reason someone "has to" hand-write a file and quietly breaks the new rule.
• Generators inside a package directory. make:model in a package repo writes to the host app's paths by default. Either run the generator from the consuming app, or configure --path/published stubs. Getting this wrong produces files in the wrong tree, not an error.
• --force and --no-interaction. make:* prompts for a model name if omitted; add --no-interaction in scripts/CI. --force silently overwrites existing generated files — never script it over a directory you care about.
• Flag order matters for combinations. make:model -mfs is fine; make:model --mfs is not. Document combos rather than letting people guess.
• Custom generators don't ship with the rule. Package-provided generators (make:livewire, make:filament-*, make:action) only exist if that package is installed — check php artisan list make before assuming a shortcut is available, and note in your cheat sheet which ones are project-specific.
• Version pinning. If your agent config references the guidelines by vendor path, a caret constraint means the rules change under you on composer update. Pin to ~3.0.1 (or copy the file into your repo at adoption time) if you need reviewable diffs when conventions shift.
• Extension point to prefer: publish and own the guidelines file locally. Forking the package to add a house rule guarantees merge pain on the next release; local override plus a quarterly re-sync does not.