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

symplify/coding-standard

Symplify Coding Standard provides 23 fixer rules for clean, consistent PHP code, covering array formatting, line length, and strict types. It works best with Easy Coding Standard but is deprecated in favor of using ECS directly.

View on GitHub
Deep Wiki
Context7

[Deprecated] Use ECS that includes this set with more new rules

Frequently asked questions about Coding Standard
Is symplify/coding-standard compatible with Laravel?
It is a generic PHP-CS-Fixer rule set, not Laravel-aware, so it does not understand Blade, Eloquent conventions, Artisan, or Laravel's baseline. It can technically be installed as a dev dependency with ECS in a Laravel app, but it is deprecated and not recommended for new Laravel work. Laravel ships Pint as the default formatter, which is a better fit.
How do I install symplify/coding-standard in a Laravel project?
Install it with symplify/easy-coding-standard as dev dependencies, then register the prepared set in ecs.php using withPreparedSets(symplify: true). Run vendor/bin/ecs for a dry run and vendor/bin/ecs --fix to apply changes. Composer will likely warn that the package is abandoned. For a legacy project, pin versions and plan an exit rather than adding it to new work.
Can I use symplify/coding-standard with Laravel Pint?
No, not directly. Pint uses pint.json and its own PHP-CS-Fixer configuration, while this package runs through ECS; Pint cannot load ECS config and ECS cannot consume pint.json. Running both formatters over one codebase can produce conflicting fixes and nondeterministic --fix output.
What rules does symplify/coding-standard provide?
It provides 23 fixer rules covering array formatting, line length, method chaining, constructor promoted-property layout, strict types spacing, and docblock @param, @return, and @var normalization. Some rules are useful individually, such as promoted property standalone lines and docblock cleanup. The set is generic PHP hygiene, not Laravel-specific style.
Is symplify/coding-standard still maintained?
No. The package is explicitly deprecated in its README and the repository is archived, with the maintainer directing users to ECS. There is no security response, PHP-version compatibility work, or bug triage. Betting a repository's style contract on this abandoned chain is a compounding maintenance liability.
Can symplify/coding-standard break Larastan or PHPStan?
It can affect static analysis because several docblock fixers mutate @param, @return, and @var annotations that PHPStan, Larastan, and Psalm use for type narrowing. Rules such as RemoveSuperfluousVarNameFixer, SwitchedTypeAndNameFixer, and RemoveDeadParamFixer can silently change inferred types. Treat the first fix run as a behavioural review, not just formatting.
Does symplify/coding-standard support PHP 8.4 and newer syntax?
There is no guarantee. The package is archived, so older fixer token logic may mis-parse newer PHP constructs such as property hooks, asymmetric visibility, and readonly classes. Running --fix on unparseable tokens can corrupt source, so do not apply it blindly on modern PHP codebases.
What should I use instead of symplify/coding-standard for Laravel?
Use Laravel Pint for standard Laravel formatting, or PHP-CS-Fixer directly if you need custom rules. If you specifically want the ECS prepared sets, use ECS itself rather than this deprecated wrapper. Keep one formatter in CI and pre-commit hooks to avoid rule conflicts.
How do I safely test symplify/coding-standard before applying fixes?
Run vendor/bin/ecs without --fix first and inspect the diff on a clean branch. Apply fixes in a dedicated formatting commit, review docblock changes with Larastan/PHPStan, and add .git-blame-ignore-revs to reduce blame noise. Do not mix the reformat with feature work.
Why does Composer warn that symplify/coding-standard is abandoned?
Composer reports abandoned packages because the upstream repository is archived and the README marks it deprecated. Hardened CI pipelines and dependency-review bots may treat abandoned transitive dependencies as a finding. If it is already in the tree, freeze versions, document the exception, and schedule removal.
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.
microsoft/fluentui-system-icons
mmccook/php-json-canonicalization-scheme
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core