Weave Code
Codesniffer Standard Laravel Package
shiftonelabs/codesniffer-standard
Opinionated PHP_CodeSniffer ruleset by ShiftOneLabs. Provides a shared coding standard for consistent style, formatting, and best practices across PHP/Laravel projects. Easy to install and run with phpcs in CI or local development.
CodeSniffer standard to add a few extra checks not contained in PSR-2.
Frequently asked questions about Codesniffer Standard
- How do I install this CodeSniffer standard for a Laravel project?
- Run `composer require --dev shiftonelabs/codesniffer-standard` in your Laravel project. Configure it in your `.phpcs.xml` by setting `<config name="standard" value="Shiftonelabs"/>` and specify file extensions like `php,blade.php` if needed. Ensure PHP_CodeSniffer is installed globally or via Composer (`composer require --dev squizlabs/php_codesniffer`).
- Does this package work with Laravel Blade templates (*.blade.php)?
- Yes, but you must explicitly include Blade files in your PHPCS config. Add `<arg name="extensions" value="php,blade.php"/>` and ensure your `.phpcs.xml` targets the `resources/views` directory. Some Blade-specific syntax (e.g., `@php`) may require exclusions or custom rule adjustments.
- Will this conflict with Laravel Pint or PHPStan?
- Potential overlap exists: Laravel Pint auto-fixes PSR-12, while this enforces PSR-2 + custom rules. Use PHPCS for static analysis (e.g., security checks) and Pint for formatting. Configure PHPCS to exclude auto-fixed files or vice versa. Test both tools in CI to avoid redundant failures.
- Which Laravel versions does this package support?
- This package is framework-agnostic and works with any Laravel version (5.8+) or vanilla PHP project using PSR-2. Laravel-specific considerations (e.g., Blade support) are handled via configuration, not version locking. Ensure your PHP_CodeSniffer version is compatible with your PHP runtime (e.g., 7.4+).
- How do I exclude tests or vendor files from PHPCS checks?
- Add `<exclude-pattern>*/tests/*</exclude-pattern>` and `<exclude-pattern>*/vendor/*</exclude-pattern>` to your `.phpcs.xml`. For granular control, use `<file>./app</file>` to target specific directories. PHPCS respects these patterns in both local runs and CI pipelines.
- Can I customize or extend the ruleset for my team?
- Yes, the ruleset is designed for extension. Override defaults in `.phpcs.xml` by adding `<rule ref="Shiftonelabs">` followed by custom `<exclude>` or `<error>` tags. For advanced needs, fork the package or create a custom Sniff class. Document changes in your team’s coding guidelines.
- How do I integrate this into GitHub Actions for CI?
- Add a step to your workflow YAML like this: `- name: Run PHPCS run: vendor/bin/phpcs --standard=Shiftonelabs --extensions=php,blade.php --report=github ./app`. Fail the job on errors by setting `continue-on-error: false`. Cache Composer dependencies to speed up runs.
- What if my team already uses PSR-12 or a custom Sniffs file?
- This package extends PSR-2, so conflicts may arise with PSR-12 or stricter rules. Audit your existing `.phpcs.xml` for overlaps, then either merge rules or use `<exclude>` tags to suppress redundant checks. Test thoroughly in a staging environment before enforcing in CI.
- Are there performance concerns for large Laravel projects?
- PHPCS can slow down CI for large codebases. Mitigate this by excluding non-critical paths (e.g., `storage/`, `bootstrap/`), using `--parallel` flag, or running checks incrementally. For monorepos, scope PHPCS to your Laravel app directory only. Cache results in CI with tools like `phpcs --cache`.
- How do I handle false positives, like Blade custom directives?
- False positives can be addressed via exclusions in `.phpcs.xml`. For Blade-specific issues, use `<exclude-pattern>*/views/*/@php</exclude-pattern>` or adjust the `Shiftonelabs` Sniff classes directly. Test edge cases locally before enforcing in CI. Document known exceptions in your team’s guidelines.
Weaver
How can I help you explore Laravel packages today?