- What is isaac/php-code-sniffer-standard and how does it work?
- It is a custom PHP_CodeSniffer ruleset that bundles coding-style rules for PHP projects. You install it with Composer and reference the bundled standard in phpcs.xml, then run vendor/bin/phpcs locally or in CI. It is dev-only tooling and does not affect application runtime, autoloading, or request handling.
- How do I install isaac/php-code-sniffer-standard in a Laravel project?
- Add it as a require-dev dependency alongside squizlabs/php_codesniffer using Composer. Create or update phpcs.xml to reference the bundled standard, then run vendor/bin/phpcs against your source directories. Commit the configuration so IDE plugins and CI use the same rules.
- Does isaac/php-code-sniffer-standard support Laravel 10, Laravel 11, and PHP 8.2 or 8.3?
- The package is a PHP_CodeSniffer ruleset, so Laravel version support is indirect; compatibility depends on PHP_CodeSniffer and your PHP version. Because upstream is archived, there is no guaranteed support for PHP 8.2, PHP 8.3, or newer PHPCS majors. Test installation in a branch and pin versions before relying on it.
- How does isaac/php-code-sniffer-standard compare with Laravel Pint?
- Laravel Pint is the first-party Laravel formatter built on PHP-CS-Fixer, while this package is a PHP_CodeSniffer ruleset. Their rules can overlap or conflict, so running both without a clear owner invites contradictory auto-fixes. In a Laravel stack, treat Pint as the default and use PHPCS only for non-overlapping checks such as naming, complexity, or strict types.
- Is isaac/php-code-sniffer-standard still maintained?
- No. The upstream repository is archived, so there are no patches, no PHPCS 4.x compatibility work, and no PHP 8.x sniff updates. It also has zero dependents and roughly 10 stars, meaning the rules are largely unvalidated in the wild. The MIT license lets you fork and vendor it, which is the main mitigation.
- What dependencies does isaac/php-code-sniffer-standard require?
- It depends on squizlabs/php_codesniffer and may also pull in slevomat/coding-standard, so check composer.json for exact constraints. Because the package is archived, those constraints can block installation on newer PHPCS majors or PHP versions. Pin exact versions in your project or internal fork and treat PHPCS upgrades as tested migrations.
- Can I run isaac/php-code-sniffer-standard in a CI pipeline?
- Yes. It is designed for dev and CI use: install it with require-dev and run vendor/bin/phpcs in the pipeline. Use a PHPCS baseline so existing violations do not block adoption, then fail builds only on new violations. Measure CI runtime and false-positive rate during a pilot before rolling it out widely.
- How do I customize or override rules in isaac/php-code-sniffer-standard?
- Create your own phpcs.xml that includes the Isaac standard and then excludes specific sniffs or adjusts severities. You can also copy the ruleset into a project-specific standard and edit the sniff list directly. For Laravel projects, decide whether Pint or PHPCS is authoritative to avoid contradictory fixes.
- Is isaac/php-code-sniffer-standard safe to use in production?
- It is dev-only tooling with no runtime surface, so security risk in production is negligible. Keep it in require-dev and exclude it from production images or deployment artifacts. The main risk is maintenance and CI breakage from stale dependencies, not exploitation.
- Should I fork isaac/php-code-sniffer-standard or use an alternative?
- Fork or extract rather than depend if you need long-term stability. The ruleset is small enough that copying the ruleset XML into an internal package under the MIT license is practical. Then baseline existing code and ratchet only new changes. Alternatives include Laravel Pint, PSR-12, or an internal PHPCS standard.