Layouts Coding Standard Laravel Package

Technical Evaluation

Architecture fit. netgen/layouts-coding-standard is a development-time tooling artifact, not a runtime dependency. It ships a PHP_CodeSniffer ruleset — XML/PHP rule definitions encoding Netgen's conventions (broadly PSR-12 plus Netgen-specific rules around layout/bundle classes, Doctrine, and Slevomat) — with no service providers, no autoloaded application code, and zero production footprint. Fit is therefore binary rather than a spectrum: it is a strong fit if the codebase is Netgen Layouts or an extension/distribution built on it, and near-worthless otherwise. The "Laravel/PHP package" framing in the request is a mismatch worth flagging to stakeholders up front: Netgen Layouts is a Symfony bundle, and nothing here is Laravel-specific. A TPM should treat this as a platform-alignment decision (adopt the vendor's own standard) rather than a feature evaluation.

Integration feasibility. Mechanically trivial — a composer require --dev with an exact pin, a project phpcs.xml.dist that references the packaged ruleset, and a CI job. The real effort is not installation; it is (a) sizing the remediation backlog on existing code, (b) resolving overlaps with whatever standard the team already runs (PSR-12, Slevomat, Doctrine, or Laravel Pint), and (c) naming an owner. A TPM should scope this as a one-to-two sprint enablement item, not a ticket, because the violation surface is usually much larger than expected and mechanical phpcbf changes must be committed separately from functional work to keep diffs reviewable.

Technical risk. Low in production terms, moderate in stewardship terms.

• Runtime risk: none — dev dependency only.
• Toolchain risk: the ruleset likely assumes a specific PHP_CodeSniffer major (3.x vs 4.x) and a PHP version floor. Those constraints can collide with the rest of the toolchain, and the collision surfaces as a red build rather than a clear error.
• Co-existence risk: running two standards over the same tokens produces duplicate or contradictory sniffs; teams resolve this by disabling rules wholesale, which silently erodes the control.
• Noise risk: sniffs tuned for Netgen Layouts source applied to general application code generate false positives, which is the fastest path to the ruleset being ignored.
• Stewardship risk (dominant): 0 stars, 0 dependents, single-vendor origin, no external users, no issue traffic. There is no community backstop, so you will be the first to discover breakage and there is no signal about whether anyone is maintaining it.

Key questions. Which PHP_CodeSniffer major does it target, and does that match our CI? Is it a standalone ruleset.xml or does it extend another standard (and are those standards pulled in transitively by Composer)? What PHP version floor does it declare? Are there stable Packagist tags, or only dev branches? Does it ship fixers (PHPCBF-compatible) or is it sniff-only? Is the package's own CI green, and are the sniffs themselves tested? Is there a documented compatibility matrix against Netgen Layouts releases? For a TPM the first four determine feasibility; the last three determine whether we vendor or depend.

Integration Approach

Stack fit. Drop-in if you already run PHPCS and build on Netgen Layouts. If the team standardizes exclusively on Pint/PHP-CS-Fixer, adopting this creates two competing owners of code style — pick one, do not run both. If the product is Laravel without Netgen Layouts, the correct answer is skip: use PSR-12 plus a maintained general-purpose standard (Slevomat, Doctrine) or extend the org standard. Fragmentation into per-framework standards adds more cognitive overhead than it removes unless the framework is genuinely in use.

Migration path.

1. Add as a pinned dev dependency — exact version, never a floating `^