- How do I install phpmyadmin/coding-standard in a Laravel project?
- Install it as a dev dependency with composer require --dev phpmyadmin/coding-standard. Because it is a PHP_CodeSniffer ruleset rather than a Laravel package, there is no service provider, config file to publish, or migration step. Composer pulls doctrine/coding-standard and slevomat/coding-standard transitively, and that is the entire footprint. After installation you only need to reference the PhpMyAdmin standard name from your ruleset.
- Does phpmyadmin/coding-standard work with Laravel 10 and Laravel 11?
- Yes, but not because of any Laravel version support, since the ruleset has no framework coupling at all. It is a PHP_CodeSniffer standard, so compatibility depends on your PHP version and the PHPCS version you run, not on the Laravel release. That also means it knows nothing about Laravel idioms such as facades, helper functions, or attribute-based configuration. Expect it to be either silent or overly strict on modern Laravel patterns rather than Laravel-aware.
- How do I configure phpcs.xml.dist to use the PhpMyAdmin standard?
- Create or edit phpcs.xml.dist in the project root and add a rule element referencing the PhpMyAdmin standard, for example rule ref set to PhpMyAdmin. Add file entries for app, routes, config, and database, and exclude-pattern entries for vendor, storage, bootstrap/cache, and resources/views. Then run vendor/bin/phpcs with no arguments so it picks up the ruleset automatically. Most teams also add a Composer script such as composer lint so the check is a single command.
- Can I run phpmyadmin/coding-standard alongside Laravel Pint?
- You can, but you must decide which tool owns formatting before you do. Pint is PHP-CS-Fixer based and auto-fixes, while PHPCS reports and phpcbf fixes only a subset of sniffs. Running both without a declared boundary produces reformat-then-reflag loops in CI and pre-commit hooks. A workable split is Pint for whitespace and import ordering, and PHPCS for the extra structural rules phpMyAdmin layers on top of Doctrine.
- Why does the PhpMyAdmin standard flag code that looks correct in Laravel?
- The ruleset is a thin layer over doctrine/coding-standard, and those sniffs were written for Doctrine and phpMyAdmin codebases rather than for Laravel. Idiomatic constructs such as facades, global helpers, and certain array or docblock patterns can trip sniffs that were never designed with them in mind. The usual fix is to override or exclude the specific offending sniffs in phpcs.xml.dist instead of abandoning the standard. Every override is code you now maintain, so keep the exclusion list short and documented.
- Which directories should I exclude from PHPCS in a Laravel app?
- Exclude resources/views because Blade templates are not scannable PHP and will only generate noise. Also exclude vendor, storage, bootstrap/cache, node_modules, and any generated or build output. Decide explicitly whether tests should be scanned, since many teams run a looser separate ruleset there. Getting exclusions right up front is what keeps the CI gate credible instead of ignored.
- Does phpmyadmin/coding-standard fix code automatically?
- Only partially. PHP_CodeSniffer ships phpcbf, which can auto-fix a subset of violations, mostly whitespace and simple formatting. Coverage is noticeably narrower than Pint or php-cs-fixer, and many Doctrine-derived sniffs require manual edits. If your team expects one command that cleans the whole codebase, that expectation belongs with Pint, not with this ruleset.
- Can I extend or override the phpMyAdmin ruleset for my own project?
- Yes. In phpcs.xml.dist you can reference the PhpMyAdmin standard and then add rule elements that change severity, exclude specific sniffs, or add your own sniff configuration on top. This is normal PHPCS behaviour and is the intended way to adapt a third-party standard. Be aware that heavy overriding effectively turns the ruleset into an in-house fork you maintain. Keeping a short, documented list of deviations is far cheaper than rewriting the standard.
- What are the alternatives to phpmyadmin/coding-standard for a Laravel project?
- The Laravel-native option is laravel-shift/php-coding-standards, which is written for this exact framework context. Laravel Pint handles formatting and is already installed by default. If you want the underlying base without phpMyAdmin's overrides, use doctrine/coding-standard or slevomat/coding-standard directly. Choose phpmyadmin/coding-standard only if you specifically want phpMyAdmin's opinionated layer over Doctrine.
- Is phpmyadmin/coding-standard actively maintained and safe to use?
- It is safe in the sense that it is a dev-only tool with no runtime surface, so it cannot break production. The real risk is adoption and maintenance: the repository has very few stars and dependents, and its roadmap is phpMyAdmin's internal backlog rather than yours. Verify actual tags and commit activity before treating it as actively maintained, and pin the version in composer.json so upgrades are deliberate. Most releases are Doctrine base bumps, which can introduce new sniffs across the whole codebase at once.