Getting incorrect Exit Code with PHPCBF

[JohnnyWalkerDigital]

Unexpected Exit Code from PHPCBF

Let's say I have a rule to enforce every file starting with declare(strict_types=1); like:

<rule ref="SlevomatCodingStandard.TypeHints.DeclareStrictTypes">
    <exclude-pattern>tests/*</exclude-pattern>
    <properties>
        <property name="linesCountBeforeDeclare" value="1" />
        <property name="linesCountAfterDeclare" value="1" />
        <property name="spacesCountAroundEqualsSign" value="0" />
    </properties>
</rule>

I then deliberately remove declare(strict_types=1); from one file and run ./vendor/bin/phpcbf.

This is the output I see:

.........................................F..................  60 / 125 (48%)
............................................................ 120 / 125 (96%)
.....                                                        125 / 125 (100%)



PHPCBF RESULT SUMMARY
----------------------------------------------------------------------------------------------------------------------------------
FILE                                                                                                              FIXED  REMAINING
----------------------------------------------------------------------------------------------------------------------------------
.../home/Library/Project/app/View/Components/PersonLayout.php  1      0
----------------------------------------------------------------------------------------------------------------------------------
A TOTAL OF 1 ERROR WERE FIXED IN 1 FILE
----------------------------------------------------------------------------------------------------------------------------------


Time: 4.83 secs; Memory: 32MB

My understand is that, according to the documentation, the Exit Code should be 0: "clean code base / auto-fixed with no issues remaining".

However in this instance, I'm getting the Exit Code 2: "issues found/remaining, non-auto-fixable"

This is very confusing to me because the number of remaining issues is zero.

UPDATE:
I was suppressing any warnings with -n. This seems to be related to the issue. If there are non-fixable warnings and they are suppressed with -n then the exit code reflects the existence of those unfixable warnings, rather than the suppressed output.

Code sample (updated)

#!/bin/bash

# Run PHP_CODESNIFFER fixer
./vendor/bin/phpcbf -n
result=$?

printf "Exit Code: %s\n" "$result"

Custom ruleset (updated)

    <rule ref="SlevomatCodingStandard.TypeHints.DeclareStrictTypes">
        <exclude-pattern>tests/*</exclude-pattern>
        <properties>
            <property name="linesCountBeforeDeclare" value="1" />
            <property name="linesCountAfterDeclare" value="1" />
            <property name="spacesCountAroundEqualsSign" value="0" />
        </properties>
    </rule>
    <rule ref="Generic.Files.LineLength">
        <properties>
            <property name="lineLimit" value="120"/>
            <property name="absoluteLineLimit" value="0"/>
        </properties>
    </rule>

To reproduce (updated)

Steps to reproduce the behavior:

1. Create a file called test.php opening <?php without declare(strict_types=1); and with a line exceeding 120 chars
2. Add custom ruleset above
3. Create a file called check.sh that will display the Exit Code for you (use code above)
4. Run bash check.sh
5. See Exit Code is returned as 2

Expected behavior

Exit Code should be 0.

Versions (please complete the following information)

Operating System	MacOS 26.2
PHP version	8.4
PHP_CodeSniffer version	4.0.1 (stable)
Standard	PSR12
Install type	Composer (global)

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.

[jrfnl]

@JohnnyWalkerDigital Thanks for opening this issue. Unfortunately, it doesn't contain enough/the right information to be reproducible.

Tried to reproduce with the following (as roughly per your above reproduction steps) and failed:
File phpcs-1372.php:

<?php

Ruleset phpcs-1372.xml:

<?xml version="1.0"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="1372" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/PHPCSStandards/PHP_CodeSniffer/master/phpcs.xsd">
	<rule ref="SlevomatCodingStandard.TypeHints.DeclareStrictTypes">
	    <properties>
	        <property name="linesCountBeforeDeclare" value="1" />
	        <property name="linesCountAfterDeclare" value="1" />
	        <property name="spacesCountAroundEqualsSign" value="0" />
	    </properties>
	</rule>
</ruleset>

I also made sure that:

• the PHPCS instance which I used to run the test had the SlevomatCodingStandard registered in its installed_paths.
• the PHPCS instance which I used was set up to always show the exit code.

Then I first ran:

$ phpcs -ps --basepath=. ./phpcs-1372.php --standard=phpcs-1372.xml

E 1 / 1 (100%)

FILE: phpcs-1372.php
----------------------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------------------------------------------------------------------
 1 | ERROR | [x] Missing declare(strict_types=1). (SlevomatCodingStandard.TypeHints.DeclareStrictTypes.DeclareStrictTypesMissing)
----------------------------------------------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------------------------------------------------------------------

Time: 232ms; Memory: 4MB

Exit code is 1

Next I ran:

$ phpcbf -ps --basepath=. ./phpcs-1372.php --standard=phpcs-1372.xml

F 1 / 1 (100%)

PHPCBF RESULT SUMMARY
----------------------------------------------------------------------
FILE                                                  FIXED  REMAINING
----------------------------------------------------------------------
phpcs-1372.php                                        1      0
----------------------------------------------------------------------
A TOTAL OF 1 ERROR WERE FIXED IN 1 FILE
----------------------------------------------------------------------

Time: 233ms; Memory: 4MB

Exit code is 0

I ran this test with the PHPCS 4.x branch.

As you can see, the issue is not reproducible with the provided information.

Marking this issue as a close candidate until additional information would be provided demonstrating the issue reported actually exists.

I'd like to suggest you:

• Run phpcs over your codebase to see what non-fixable error(s) remain.
• Check composer global info to verify that you are actually running on PHPCS 4.x and not on 3.x (the exit codes were changed in 4.0).
• Add information such as the relevant parts of your composer.json file and possibly the output of phpcs --config-show if that would help make the issue reproducible.

[JohnnyWalkerDigital]

Thank you for your help! This is great news. (Note: I realised that I put Composer (global) but I should have written Composer (local). Nonetheless, composer info confirms v4.0.1.)

After more digging it seems it's the presence of warnings that lead to Exit Code 2 from phpcbf.

I discovered the relevant documentation that explained this. I was suppressing warnings from my output so wasn't seeing them.

I need to ignore warnings when generating Exit Codes. Thanks!

[jrfnl]

@JohnnyWalkerDigital Would you please share how you were suppressing warnings ? Are you using the -n option ?

[JohnnyWalkerDigital]

@jrfnl Yes

[jrfnl]

@JohnnyWalkerDigital I've just run some more tests and for the life of me, I cannot reproduce what you are saying.

For my own sanity and to safeguard the existing behaviour, I've added some more integration tests and they also confirm that warnings do not influence the exit code when using the -n option.

See PR #1376.

I need to ignore warnings when generating Exit Codes.

You should not need to do this. The -n option alone already means that warnings will be ignored completely, including for the exit code (as confirmed by the tests).

I'd truly like to understand how you are getting a non-zero exit code given the issue as described, but without additional information, I'll close this issue as not reproducible.

[rodrigoprimo]

Just noting that I also tried to reproduce the problem described in this issue and was unable to.