Generelle Laravel Prinsipper Laravel Package

Technical Evaluation

What v3.0.1 actually changes: a single added principle — always prefer php artisan commands where they exist (e.g. make:*) when creating new files. This is a guidance/convention change, not a code or API change, shipped as a patch bump.

Architecture fit: The package occupies the conventions/standards layer of a Laravel codebase rather than the runtime layer. It does not introduce service providers, middleware, or runtime coupling that would affect application architecture. Fit is therefore high for teams that already standardise on Laravel's generator workflow, and neutral for teams that don't use make:* at all.

Integration feasibility: Low effort. If consumed as a Composer dependency it is a version bump; if consumed as documentation/agent guidelines it is a copy-and-adopt change. No migration of application code is implied by the release note.

Technical risk: Low, with three caveats:

1. The principle is unenforced. A guidance-only rule with no linter, static analysis, or CI check drifts silently; nothing in this release indicates an enforcement mechanism.
2. Semver signal is weak. A patch bump on a conventions package tells us little about behaviour change, so consumers cannot triage by version number alone.
3. Localisation mismatch. Release notes are in Norwegian while the artefact presumably targets an English-language Laravel codebase; this is an onboarding and auditability friction point, not a blocker.

Key questions before committing:

• Is this package documentation-only, or does it ship enforceable config (PHPStan/Rector/Pint rulesets, CI templates, AI-agent instruction files)?
• What are the PHP and Laravel version constraints, and which Laravel majors are supported at v3.0.1?
• What changed between v2 and v3.0.0? There is no changelog evidence in this release note for the major version boundary, which is the one thing a TPM must resolve before an upgrade decision.
• Who is the upstream owner, and what is the release cadence and issue-response history?
• Is there an English version of the guidance, or is Norwegian the source of truth?
• Does the "always use artisan" principle conflict with any in-house scaffolding, domain generators, or IDE-driven file creation already standardised?

Integration Approach

Stack fit: Assume a standard Laravel application or package consuming conventions. Because the release note is guidance-level, the practical integration is: add the package to require-dev (or vendor the guidelines), then wire it into the team's contribution workflow rather than into application bootstrap.

Migration path: Treat v3.0.1 as the target and pin ^3.0. Do not schedule an upgrade until the v2→v3.0.0 diff is reviewed — the major bump is the actual risk surface, and this patch note gives no visibility into it. If already on v3.0.0, the upgrade is effectively a no-op and can ride along with the next routine dependency update.

Compatibility checks (gate before merge):

• composer why-not against the target Laravel and PHP versions in each adopting repo.
• Confirm the package does not pull in transitive dev dependencies that collide with existing Pint/PHPStan/Rector pins.
• Confirm whether the guidance assumes make:* availability in all contexts (packages vs applications; artisan absent in some package-only repos).

Sequencing:

1. Spike (1–2 days): read the package contents, answer the enforcement question, and capture the v3.0.0 changelog. This determines whether the effort is "add a file" or "add a toolchain component."
2. Pilot in one repo: adopt on the highest-traffic application repo, wire the artisan-first principle into CONTRIBUTING.md and the PR template, and measure whether reviewers actually cite it.
3. Codify, don't just document: if the principle matters, pair it with a mechanical check (a CI grep for hand-created files under app/, or a generator-first scaffolding script) so it survives beyond a README line.
4. Roll out to remaining repos once the pilot shows the guidance is being followed without reviewer prompting.
5. Defer any v2→v3 migration to a separate tracked piece of work with its own risk review.

Operational Impact

Maintenance: Near-zero ongoing engineering cost in the adopting repos — there is no runtime surface. The real cost is ownership: someone must own the guidance artefact, keep it aligned with Laravel's evolving generator commands, and re-publish when release names change. Un-owned convention packages rot within two Laravel majors.

Support: The artisan-first principle is self-explaining and reduces a recurring class of support questions ("where should this file go?", "why is this class in the wrong namespace?"). Expected support load is a short spike at adoption, then slightly lower baseline because generators produce conventionally-correct paths and namespaces.

Scaling: Scales cheaply and non-linearly well. One guidance change propagates to every repo and every new hire at effectively zero marginal cost, and it composes with existing make:* tooling. This is the main argument for adopting it rather than writing a bespoke internal equivalent.

Failure modes:

• Silent drift: guidance diverges from practice because nothing enforces it; mitigated by pairing with a CI check or PR-template prompt.
• Conflict with in-house generators: teams with custom scaffolding may read "always use artisan" as prohibiting their own commands; the principle needs an explicit "including your own custom make:* commands" clarification.
• Stale after Laravel upgrades: renamed or removed generator commands invalidate the guidance with no automated signal.
• Localisation and auditability: Norwegian-only release notes slow review for non-Norwegian reviewers and complicate vendor-risk documentation.
• Low-signal versioning: patch-level convention changes mean consumers cannot rely on semver for triage and must actually read release notes.

Ramp-up: Effectively zero for engineers — one read of the principle, applied immediately. Budget roughly half a day for a TPM/tech-lead to close the open questions (v3 changelog, enforcement story, version support matrix) before this is treated as an approved standard rather than an individual repo's preference.