mnapoli/pretty

✨ CLI command with sane defaults to simplify CodeSniffer and PHP-CS-Fixer

A single CLI command with sane defaults to simplify CodeSniffer and PHP-CS-Fixer.

---

PHP CodeSniffer and PHP-CS-Fixer are powerful but using them is not simple. It is not always obvious which tool a project uses and whether there is a configuration file to use or whether you need to provide options to the CLI command.

Now it's easy, simply run:

pretty

Pretty will detect the configuration file that exist in the current directory and will run the correct tool. If no configuration file exist, Pretty will run PHP CodeSniffer with PSR-2 by default.

If errors are found, simply run:

pretty fix

Again, Pretty will run the appropriate tool (php-cs-fixer or phpcbf) to fix as many errors as possible in your code.

Installation

If you have already set up a global install of Composer just run:

composer global require mnapoli/pretty

Pretty comes with no dependencies so it should not bring any conflict in Composer.

You can also install it as a local dependency of your project with composer require --dev mnapoli/pretty. In that case you can start the tool with vendor/bin/pretty.

You will be able to update to new versions by running:

composer global update mnapoli/pretty

Usage

Running an analysis is as simple as running:

pretty

This command will not change any code. To fix errors reported by this command, simply run:

pretty fix

In case you are running the analyses in CI you might want to run:

pretty ci

This will disable the caching option of PHP-CS-Fixer or CodeSniffer (because the cache will not be kept in CI).

Hosted continuous integration

If you are using pretty in your daily development workflow you may be interested in PrettyCI.com, the SaaS version of pretty.

pretty's Issues

Windows

Due to an undisclosed need, i had to run pretty on Windows.
When running pretty i got:

ERROR: PHP CodeSniffer does not seem to be installed because the 'phpcs' program cannot be found.

It was strange because i had phpcs installed and i could run it just fine. After looking trough this code i noticed that the error message comes from:

function commandExists($command)
{
    $return = shell_exec('which ' . escapeshellarg($command));
    return !empty($return);
}

which cannot be installed on Windows, so i just changed the above code to

function commandExists($command)
{
   return true;
}

And poof everthing started working just fine :)
Hope this will help somebody else.

Result \array_key_exist is different to prettyci.com

When using Symfony rules the local will add the slash \array_key_exist but the CI want that you remove it. It seems like the CI is using an older version of the php-cs-fixer.

False positives for PSR12 on PHP 7.4.2

PrettyCI is returning errors from PHPCS when running PHPCS locally with the same .phpcs.xml file reports no errors so I don't believe this is a PHPCS issue.

The errors themselves reported aren't issues, and if changed, would actually introduce changes no longer compliant with PSR12.

Here are the results of my latest run showing the two issues:
https://github.com/aran112000/Form-Generator/runs/418127387

Specifically, these are the issues being flagged:

Expected at least 1 space after "?"; 0 found

protected ?string $value = null;

Expected at least 1 space before ":"; 0 found

public function getId(): string

Running "pretty" on brefphp/bref

> pretty fix
PHP CodeSniffer configuration file found, running CodeSniffer with version
ERROR: PHP CodeSniffer does not seem to be installed because the 'phpcbf' program cannot be found.
You can install it by following the instructions here: https://github.com/squizlabs/PHP_CodeSniffer#installation
> composer global require "squizlabs/php_codesniffer=*"
(successfully installed)
>  pretty fix                                           
PHP CodeSniffer configuration file found, running CodeSniffer with version
PHP_CodeSniffer version 3.4.2 (stable) by Squiz (http://www.squiz.net)

ERROR: Referenced sniff "Doctrine" does not exist

Run "phpcbf --help" for usage information

Errors were found, run 'pretty fix' to fix them.

I have to somehow figure out that I must run composer global require doctrine/coding-standard. (Or maybe there is another way?)

We are now a long way from php-fixer fix which was something I liked with pretty ci.

Anyhow, I maybe should have opened this issue on Bref. I just wanted to share some frustration.

Support local (vendor) installations of phpcs and php-cs-fixer

Pretty runs tools installed globally.

It would be great if it worked with tools (phpcs/php-cs-fixer) installed locally in the project, in the vendor/ directory.

Getting error, when using "PHP CS Fixer version 0.3-DEV"

→ pretty fix
PHP-CS-Fixer configuration file found, running PHP-CS-Fixer with version
PHP CS Fixer version 0.3-DEV by Fabien Potencier



                                              
  [RuntimeException]                          
  The "--allow-risky" option does not exist.  
                                              


fix [--config="..."] [--dry-run] [--level="..."] [--fixers="..."] [--diff] [--format="..."] path


Errors were found, run 'pretty fix' to fix them.

No configuration file found

I get this error when running pretty:

No configuration file found, running PHP CodeSniffer with PSR-2

I have a .phpcs.xml file in the project and I have also tried renaming it to .phpcs.xml.dist but I get the same result and it defaults to PSR-2. When I execute phpcs using vendor/bin/phpcs . it runs fine.

Is there something else I am missing?

Force --no-colors in PHP_CodeSniffer CLI

PHP_CodeSniffer currently doesn't support autodetection of whether STDOUT is a TTY, so projects (e.g. doctrine/dbal) specify colors in their configuration for developer’ convenience. If PHP_CodeSniffer with such settings runs on Travis, it’s fine because interprets ANSI output.

At the same time, it doesn't seem to be the case for GitHub Checks. So the colored output is displayed as control characters (example).

Would it make sense to force --no-colors in the phpcs command line arguments? It seems to suppress the color argument from the XML configuration.

Clean Way Inspiration

Just in case you'd like to use something else than default and not reinvent the wheel :)
https://github.com/Symplify/EasyCodingStandard#the-easiest-way-to-use-any-coding-standard

Feature: Run fixer without automatically creating cache

Don't know about phpcs, but cs-fixer will automatically create the cache file, if none exists, unless run with a --using-cache. If someone switches from one fixer to the other; files like this would become mess...