Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Coding Standard

Coding Standard Laravel Package

phpmyadmin/coding-standard

PHP_CodeSniffer ruleset from phpMyAdmin, built on the Doctrine Coding Standard, for enforcing consistent PHP code style. Install it with Composer as a dev dependency, then run vendor/bin/phpcs --standard=PhpMyAdmin against your codebase to catch style issues early.

View on GitHub
Deep Wiki
Context7

phpMyAdmin Coding Standard is a PHP_CodeSniffer ruleset based on the Doctrine Coding Standard, providing consistent coding conventions for phpMyAdmin and compatible PHP projects. It helps teams enforce uniform style and catch formatting issues during development or CI.

  • Built on the Doctrine Coding Standard
  • Custom PhpMyAdmin ruleset for project-specific conventions
  • Integrates directly with PHP_CodeSniffer
  • Install as a dev dependency via Composer
  • Run with vendor/bin/phpcs --standard=PhpMyAdmin /path/to/code
Frequently asked questions about Coding Standard
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.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
rlacerda83/query-parser
socialdept/atp-orm
cboxdk/laravel-assistant-client
socialdept/atp-resolver
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings
coleus/apps
seampact/laravel
emmyconceptng/laravel-ng-postcode