Weave Code
Layouts Coding Standard Laravel Package
netgen/layouts-coding-standard
Coding standard for Netgen Layouts projects, providing PHP_CodeSniffer rules and configuration to enforce consistent PHP code style across packages. Helps teams keep Layouts-based codebases clean, readable, and compliant with shared conventions.
Coding standard for Netgen Layouts
Frequently asked questions about Layouts Coding Standard
- What is netgen/layouts-coding-standard used for?
- It is a PHP_CodeSniffer ruleset that encodes the coding standard Netgen uses across its Layouts projects. You add it as a dev dependency so PHPCS can check formatting, naming and code structure in your own Layouts-based code. It is tooling only: it registers no service providers, autoloads no application code and has zero production footprint, so it never ships at runtime.
- How do I install netgen/layouts-coding-standard with Composer?
- Install it as a development dependency with composer require --dev netgen/layouts-coding-standard. Pin an exact version rather than a floating constraint so an upstream ruleset change cannot turn your build red unexpectedly. After installing, point your project phpcs.xml.dist at the packaged ruleset and commit that file so every developer and CI job uses the same configuration.
- Is netgen/layouts-coding-standard a Laravel package?
- No. Netgen Layouts is a Symfony bundle, and this package encodes the vendor's conventions for Layouts code; nothing in it is Laravel-specific. If your codebase is plain Laravel without Netgen Layouts, you get little value and should use PSR-12 plus a maintained general-purpose standard or your own org standard instead. Treat adoption as a platform-alignment decision, not a feature evaluation.
- Which PHP and PHP_CodeSniffer versions does the ruleset require?
- Check the require and require-dev blocks in the package's composer.json before adopting, because the ruleset likely assumes a specific PHP_CodeSniffer major (3.x versus 4.x) and a PHP version floor. Those constraints can collide with the rest of your toolchain, and the collision usually surfaces as a failing build rather than a clear error message. Confirm the versions match your CI image and your existing PHPCS setup before you scope any remediation work.
- How do I configure phpcs.xml.dist to use this ruleset?
- Create a phpcs.xml.dist at your project root, reference the packaged ruleset from the vendor directory in a rule element, then list the files and directories you want scanned. Keep the configuration in version control so local runs and CI behave identically. If the package extends another standard, make sure any parent standard it depends on is pulled in transitively by Composer or declared explicitly.
- Can I customize or exclude rules for my own project?
- Yes. Project-specific exclusions and customization are part of what the ruleset is designed for, so you can exclude paths such as generated code, migrations or legacy directories and override individual sniffs. Keep exclusions narrow and documented; disabling whole sniffs just to make a build pass silently erodes the value of the standard. Review the exclusion list periodically and shrink it as the codebase is cleaned up.
- Does it support automatic fixing with PHPCBF?
- That depends on whether the sniffs it ships expose fixers, so run phpcbf in dry-run mode on a sample of your code before planning any rollout. Where fixes are available, run them as a separate commit from functional changes so the diffs stay reviewable. Anything phpcbf cannot fix becomes a manual remediation backlog item that needs an owner and a deadline.
- How do I run netgen/layouts-coding-standard in CI?
- Add a CI job that runs vendor/bin/phpcs against your configured paths and fails the build on violations, ideally as a separate pipeline stage from tests. Running it on changed files first keeps early feedback fast, while a full run on the main branch prevents drift. Install the dependency with the same pinned version in CI as locally so results do not diverge.
- Can I use it alongside Laravel Pint or PHP-CS-Fixer?
- Running two code-style owners over the same tokens produces duplicate or contradictory sniffs, and teams usually resolve that by disabling rules wholesale. Pick one standard per repository: PHPCS with this ruleset, or Pint/PHP-CS-Fixer with your org standard, not both. If you must migrate, do a single mechanical pass and remove the old configuration in the same change so the toolchain has one clear source of truth.
- Is netgen/layouts-coding-standard maintained, and what are the alternatives?
- Community signals are thin: it is a single-vendor package with no visible external user base or issue traffic, so there is no backstop if it breaks. Check Packagist for stable tags versus dev branches and confirm the package's own CI is green. If you are not on Netgen Layouts, use PSR-12 combined with a maintained standard such as Slevomat or Doctrine sniffs; if you are on Layouts, pin the version and consider vendoring the ruleset so upstream changes cannot surprise your build.
Weaver
How can I help you explore Laravel packages today?