Disable report for phpcbf

[GaryJones]

Is there a way to disable reporting for phpcbf?

Something like: phpcbf -q --report=none .?

[gsherwood]

No, but which output do you want to suppress? The output showing you which files are being fixed and or the final report showing you what was done (or both)?

You could always redirect STDOUT to /dev/null (or NUL for Windows, I think it is) if you want no output at all.

[gsherwood]

Sorry, should have mentioned -q works, but only suppresses that progress output. The final report still shows, so you are probably wanting to suppress that, which there is no way to do.

[GaryJones]

My use case: generating files with zend-code (via a composer script), which doesn't completely comply with PSR-2. Running phpcbf automatically after generation, I have no need for any report to show i.e. silent fixing, since it's just removing redundant blank lines that break PSR-2 compatibility.

> /dev/null seems to work in terms of hiding the output from phpcbf, though Composer is giving me a notice that the script returned with error code 1.

"generate-types": "vendor/bin/soap-client generate:types --config ./config/generate.php && phpcbf -q src/SoapTypes > /dev/null && echo \"Types have been generated to src/SoapTypes. (Ignore the error code message.)\"",

Even with the report still showing, the error code message still persists. Is there a way to override that?

[gsherwood]

The exit codes tell you what PHPCBF did, and can not be changed using config settings:

• Exit code 0 is used to indicate that no fixable errors were found, so nothing was fixed
• Exit code 1 is used to indicate that all fixable errors were fixed correctly
• Exit code 2 is used to indicate that PHPCBF failed to fix some of the fixable errors it found
• Exit code 3 is used for general script execution errors

I'm not sure what config options you have, but if you can have the script error only on exit codes > 1 then it would make more sense. Otherwise, you'll need to see if you can ignore the exit code for PHPCBF if you don't actually care what it did.

[GaryJones]

The exit code here is 1: phpcbf fixed everything that could be fixed (running phpcbf again doesn't give me any exit code message).

Composer custom scripts don't appear to have a way to override the exit code, so even though PHPCBF was 100% successful, it's still reported with a big scary red message.

I have found one workaround though. The relevant part of my script:

phpcbf -q src/SoapTypes > /dev/null || true

---

It still might be useful for some to have phpcbf output no report and no error code, but for now at least, my issue is solved. I'm leaving the issue open in case you wish to pursue, but otherwise, it can be closed.

[gsherwood]

Glad you found a solution for your case. I think an option to disable reporting (or at least change the exit code) would be helpful.

[jrfnl]

It may be an idea to add an option to use industry standard exit codes ? Something like --exit-codes=zero-based

I realize changing the codes now would break BC too much, but adding an option to use the more common standard of 0 = success, non-0 = failure could be helpful.

I would expect the current exit codes of 0 and 1 to both report as 0 (success) in that case.

Refs:

• http://tldp.org/LDP/abs/html/exit-status.html
• https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html
• http://pubs.opengroup.org/onlinepubs/9699919799//utilities/V3_chap02.html#tag_18_08_02
• https://en.wikipedia.org/wiki/Exit_status

[jrfnl]

Related: #1359

[remorhaz]

Another solution is to check the exit code directly after running phpcbf (it worked for me for running it via Composer script):

vendor/bin/phpcbf; if [ $? -eq 1 ]; then exit 0; fi

[jrfnl]

@gsherwood Is the changing of the exit code for phpcbf as proposed in https://github.com/squizlabs/PHP_CodeSniffer/issues/1818#issuecomment-354611665 something which could be earmarked for PHPCS 4.0 ?

[gsherwood]

Is the changing of the exit code for phpcbf as proposed in #1818 (comment) something which could be earmarked for PHPCS 4.0 ?

Yep. Perfect time to redo them for both PHPCS and PHPCBF. I'll throw an issue in.

[b-hayes]

Is there any way to get a code for "There are errors that can't be fixed" instead of just saying its all good because they are not fixable?

eg, no namespace in psr12, snake case instead of camel case, no visibility declared etc. These are all errors and should be fixed. I would like my script to be able to tell devs "Hey there are still errors but I can't fix them"

[gsherwood]

Is there any way to get a code for "There are errors that can't be fixed" instead of just saying its all good because they are not fixable?

If you just want to know if there are errors, PHPCS is best for this. As of version 3, the PHPCS exist codes are:

• Exit code 0 is used to indicate that no errors were found
• Exit code 1 is used to indicate that errors were found but can be fixed
• Exit code 2 is used to indicate that errors were found and some can be fixed

So if you run PHPCS and get an exit code of 2, you can run PHPCBF and expect that some errors will be fixed. If you then run PHPCS again and get an exit code of 0, you know that no errors remain.

[b-hayes]

Yeah, I Was hoping to avoid checking files twice with two tools. But starting with cs and then only running fixes if necessary is a decent compromise. TY :)

[nelson6e65]

Param --runtime-set ignore_warnings_on_exit 1 works on phpcs, but it does not for phpcbf.

[nelson6e65]

There is a kind of workaround for a Composer script: Run 2 times with an OR (||), so the second time will exit 0.

{
  "cs:fix": [
    "phpcbf src/ tests/ config/ -p || phpcbf src/ tests/ config/ -q"
  ],
}

• Exit code 0 is used to indicate that no fixable errors were found, so nothing was fixed
• Exit code 1 is used to indicate that all fixable errors were fixed correctly
• Exit code 2 is used to indicate that PHPCBF failed to fix some of the fixable errors it found
• Exit code 3 is used for general script execution errors

— @ gsherwood

Looks ugly, non-DRY 😔, but it works.

[jrfnl]

@nelson6e65 Alternatively you could check the exit code of the first run in the || part of the commend. If it's 1, you should be fine.

[nelson6e65]

@nelson6e65 Alternatively you could check the exit code of the first run in the || part of the commend. If it's 1, you should be fine.

Yes, thanks. I tried, but only on linux and was uglier. 😅 How can I check the exit code cross-os? I use Windows, Fedora and Ubuntu.

[lkraav]

I use Windows, Fedora and Ubuntu.

Cross-platform is ugly. Had to roll a custom vendor/bin executable so composer exec everything would work on Windows https://github.com/conversionxl/phpcs-ruleset/commit/b0069f9d8f22c7613754e33a8824328e075801ef

[alexkuc]

Based on @nelson6e65 's code, here is more DRY albeit somewhat verbose alternative:

#!/usr/bin/env bash

phpcbf "$@"

exit=$?

if [[ $exit -eq 0 || $exit -eq 1 ]]; then
    exit 0
fi

exit $exit

[nelson6e65]

I created this Composer package for using phpcbf with Composer and lint-staged witch does not fail on warnings, usin partial worarround from https://github.com/squizlabs/PHP_CodeSniffer/issues/1818#issuecomment-735620637:

https://github.com/nelson6e65/php-code-sniffer-helpers

[rdelbem]

I created this Composer package for using phpcbf with Composer and lint-staged witch does not fail on warnings, usin partial worarround from #1818 (comment):

https://github.com/nelson6e65/php-code-sniffer-helpers

Is it possible to use it with code standard arguments, like --standard=WordPress?

[nelson6e65]

I created this Composer package for using phpcbf with Composer and lint-staged witch does not fail on warnings, usin partial worarround from #1818 (comment): https://github.com/nelson6e65/php-code-sniffer-helpers

Is it possible to use it with code standard arguments, like --standard=WordPress?

No, sorry, @rdelbem. I checked, and all parameters are detected as files.

But it already uses the phpcs loaded config (from your phpcs.xml). Have you tried it?

Maybe I can add this detection, but I think the idea is to use the configured rules (like just running phpcs . or phpcbf .).

[rdelbem]

I created this Composer package for using phpcbf with Composer and lint-staged witch does not fail on warnings, usin partial worarround from #1818 (comment): https://github.com/nelson6e65/php-code-sniffer-helpers

Is it possible to use it with code standard arguments, like --standard=WordPress?

No, sorry, @rdelbem. I checked, and all parameters are detected as files.

But it already uses the phpcs loaded config (from your phpcs.xml). Have you tried it?

Maybe I can add this detection, but I think the idea is to use the configured rules (like just running phpcs . or phpcbf .).

Having the correct xml with the desired ruleset worked perfectly. Thanks.