- 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.