The `phpcbf` tool returns exit code 2 on "No fixable errors" success in v4.0.0

[donatj]

Describe the bug

Excuse me if this is intentional, but it's kind of weird / annoying.

Prior to 4.0.0 on "No fixable errors were found" phpcbf would return a success exit code of 0

With the release of 4.0.0 phpcbf now seems to return an exit code of 2 on "No fixable errors"

It's frankly kind of weird to return a 2 on success, and it breaks our automations. That's fixable, but I want to make sure that this is an intentional change before I fix it on our side.

Code sample

vendor/bin/phpcbf ; echo 'exit code ' $?

Custom ruleset

N/A

To reproduce

Steps to reproduce the behavior:

1. Run phpcbf with no fixes made
2. Examine exit code

Expected behavior

Exit code 0

Versions (please complete the following information)

Operating System	macOS 15.6.1
PHP version	8.3
PHP_CodeSniffer version	4.0.0
Standard	custom
Install type	Composer local

Additional context

Add any other context about the problem here.

Please confirm

• I have searched the issue list and am not opening a duplicate issue.
• I have read the Contribution Guidelines and this is not a support question.
• I confirm that this bug is a bug in PHP_CodeSniffer and not in one of the external standards.
• I have verified the issue still exists in the 4.x branch of PHP_CodeSniffer.

[LorenzoRogai]

Can confirm — also in phpcs v4, “No files were checked” returns an error and fails CI, unlike v3

[jrfnl]

@donatj

Prior to 4.0.0 on "No fixable errors were found" phpcbf would return a success exit code of 0

Correct, but if fixable errors were found and fixed, the exit code in PHPCS 3.x was 1, which was even more counter-intuitive and more difficult to handle in CI (cause you had to deal with multiple possible exit codes).

With the release of 4.0.0 phpcbf now seems to return an exit code of 2 on "No fixable errors"

Actually, phpcbf returns an exit code of 0 if there are no issues (at all) remaining after auto-fixing; and it returns an exit code of 2 if there are non-auto-fixable issues remaining.

This is a fully documented intentional change in PHP_CodeSniffer 4.0.0.

Also see:

• https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki/Version-4.0-User-Upgrade-Guide#exit-codes
• https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki/Advanced-Usage#understanding-the-exit-codes
• 4.0 | Revise exit codes for PHPCS and PHPCBF commands #184
• Change the exit codes #1079

It's frankly kind of weird to return a 2 on success, and it breaks our automations. That's fixable, but I want to make sure that this is an intentional change before I fix it on our side.

The good news is that your question was already anticipated and you can just use the ignore_non_auto_fixable_on_exit flag to get an exit code of 0 when running phpcbf and all auto-fixable issues were fixed (or none found).

The choice to exit on 2 if there are non-auto-fixable issues remaining was also deliberate as different projects have different needs and a project which has no issues at all to start with, may not want to accept any new issues being introduced, while a project which has non-auto-fixable issues to start with, may accept new non-auto-fixable issues, but not auto-fixable ones.

Having the exit codes follow a predictable pattern with flags to influence the exit codes allows to satisfy all use-cases.

The only take-away I can imagine from this issue may be to differentiate the "exit message" if there are still non-autofixable issues remaining (which cause the 2 exit code).

Does that answer your question ?

[jrfnl]

@LorenzoRogai "No files were checked" returning a non-zero exit code is a) a completely different issue and does not belong in this ticket, b) an explicit new feature to PHPCS 4.0, so intentional.

The reasoning behind this is that previously a misconfigured PHPCS run would pass in CI, so nobody would notice that PHPCS wasn't actually running due to the misconfiguration.

The new "No files were checked" error fixes that.

Also see:

• https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki/Version-4.0-User-Upgrade-Guide#my-scans-are-failing-on-a-no-files-were-checked-error
• Print a message if no files were checked during a run squizlabs/PHP_CodeSniffer#1595
• Runner: error message if no files were checked during a run #1023

[jrfnl]

The only take-away I can imagine from this issue may be to differentiate the "exit message" if there are still non-autofixable issues remaining (which cause the 2 exit code).

Actually, looks like we already differentiate the exit message (since v3.12.0) - no issues found at all results in "No violations were found", issues found, while no auto-fixable issues results in "No fixable errors were found".

[jrfnl]

@donatj Did my reply answer your question ? If so, please close this issue.

[kolorafa]

Hi

I tried doing phpcbf --config-set ignore_non_auto_fixable_on_exit 1 but it does affect both phpcbf and phpcs,

Because of that:
enabling it - will not stop phpcs and return 0 if there are issues but are unfixable
not enabling it - will stop on phpcbf that only fix stuff but don't print issues

So you can't do phpcbf ... && phpcs ...;

Is the only solution to do
phpcbf ..... || true && phpcs ...
or is there command line param that will tell on runtime to ignore non-auto-fixable only for cbf?

Thanks

[jrfnl]

@kolorafa --config-set sets something as the default for the current user only. I think what you are looking for is --runtime-set which sets config settings just for a single run, which is especially useful if this is used in CI and/or Composer scripts.

You may need to check your local CodeSniffer.conf file to remove the previously added ignore_non_auto_fixable_on_exit => 1.
Then run like so phpcbf --runtime-set ignore_non_auto_fixable_on_exit 1 && phpcs.

I'm presuming that solves your issue ?