Weave Code
Coding Standard Laravel Package
libero/coding-standard
A shared coding standard for Libero PHP projects, bundling PHP_CodeSniffer rules and fixer configuration to keep Laravel codebases consistently formatted. Add it via Composer to align team style rules and CI lint checks across repositories.
Libero PHP coding standard
Frequently asked questions about Coding Standard
- How do I install libero/coding-standard in a Laravel project?
- Install it as a development dependency with composer require --dev libero/coding-standard. Then reference the package's ruleset from your phpcs.xml and add a Composer lint script that runs phpcs so the same check runs locally and in CI. The package is a PHP_CodeSniffer ruleset, so it has no production footprint.
- Does libero/coding-standard support PHP 8.2 and PHP 8.3?
- The v0.5.0 release notes describe new rules but do not state a PHP constraint change, so support depends on the composer.json shipped with the tag. Check whether the php constraint moved to ^8.x and whether the squizlabs/php_codesniffer pin moved off its older version. Until that diff is read, PHP 8.2 and PHP 8.3 viability is an open question rather than a confirmed yes.
- What new rules does libero/coding-standard v0.5.0 add?
- v0.5.0 adds eight rules: array initialization before use, no late static binding in final classes, static closures, ternary simplification, shorthand types, trailing commas, no redundant final methods in final classes, and no unnecessary semicolons. Several of these track modern PHP idioms rather than a frozen 2019 snapshot.
- Is libero/coding-standard a runtime dependency for production?
- No. It is a development-time PHP_CodeSniffer ruleset, not a runtime library, so it has no production footprint and no runtime attack surface. Install it with --dev and keep it out of production deployments.
- Why did my CI lint check fail after updating libero/coding-standard?
- Under 0.x semver, a minor bump can break consumers, and for a lint ruleset every new rule is effectively a breaking change because previously green CI can turn red with no code change. v0.5.0 added eight rules at once, so expect a large immediate diff. Pin the version and run phpcbf or fix issues deliberately before upgrading.
- How is libero/coding-standard different from Laravel Pint or php-cs-fixer?
- Many of the new rules, such as static closures, trailing commas, and short array syntax, are already expressible in Pint or php-cs-fixer. The package's value is its opinion set and bundled PHPCS configuration rather than a unique implementation. You can either adopt it as-is or harvest the rule choices into your existing Pint config.
- Can I use libero/coding-standard with PHP_CodeSniffer 4.x?
- That is not confirmed by the v0.5.0 release notes. They describe rule changes but do not say whether the squizlabs/php_codesniffer pin moved toward 4.x or whether the custom sniffs use removed APIs. Check the composer.json diff between the previous tag and v0.5.0 before relying on PHPCS 4.x.
- How do I add libero/coding-standard to a CI pipeline?
- Add it as a dev dependency, reference its ruleset from phpcs.xml, and add a Composer script that runs phpcs. Your CI step then just runs that script, for example composer lint, on the same PHP version you use locally. Keep the package version pinned so a new ruleset release does not silently break the build.
- Is libero/coding-standard actively maintained?
- v0.5.0 shows an active maintainer adding eight rules in one release, which reduces the risk of an abandoned transitive pin blocking tooling upgrades. The release cadence and content look like a maintained internal convention rather than a frozen snapshot. Still, dependents, stars, and PHPCS 4.x readiness are not established by the notes, so verify them before standardizing on it.
- How do I exclude contested rules from libero/coding-standard?
- You can exclude individual sniffs or adjust severity in your project's phpcs.xml instead of forking the ruleset. Be careful, though: rules such as shorthand types, unnecessary semicolons, and ternary simplification are style preferences, and a gate built on contested rules tends to get suppressed. Agree as a team on which of them you actually enforce.
Weaver
How can I help you explore Laravel packages today?