Add Composer scripts for code sniffing and autofixing

[oliverklee]

There now are the following new Composer scripts:

• ci: run all CI-related Composer scripts
• ci:static run the static code analysis
• phpcs run PHP_CodeSniffer
• fix fix the autofixable PHP code warnings
• phpcbf fix the autofixable PHP_CodeSniffer warnings

For starters, we have a sniff that checks that all files are in
PHP strict mode. (The CI builds do not run this check as the files
are not strict yet at this point.)

The PHP_CodeSniffer autofixer cannot make files strict, though
(as this is a non-autofixable code sniff). It will be able to
autofix other things we'll add later, though.

[oliverklee]

Some background on PHIVE:

PHIVE is a package manager for PHP development tools that installs the tools as stand-alone, GPG-signed PHARs (i.e., a PHAR contains the corresponding tool with all its dependencies). This helps avoiding dependency hell - both inter-tools as well as between a tool and the project in which it is used. (Dependency hell is e.g., when package A requires package X in version < 3, while package B requires package X in version >= 3.) (This was a real problem in some of my projects.)

In addition, this allows tools like PHPStan to be used in their current version (which requires PHP >= 7.1) without breaking Composer-installability of the project in lower PHP versions. (This also is a real problem in some of my projects.)

PHIVE is intended to be used for development tools only, and the PHIVE-installed tools are not expected to be shipped with the library package (hence the entries in the `.gitattributes), and they are also not expected to be deployed to production systems.

Dependabot currently does not update the PHIVE-installed tools yet.

[danon]

I'm not sure how would I use it. Does it mean I have to have ./tools/phpcs.phar in my local clone?

[oliverklee]

@danon You'll need PHIVE on your local machine. You then can run phive install in your project to install the tools.

[danon]

@oliverklee Wouldn't it be better if phive was in devDependencies?

[oliverklee]

@danon AFAIK, PHIVE is only available as a stand-alone PHAR, not as a Composer package (probably because it's a package manager itself).

[danon]

I'm not sure about it.

If it was a devDependency, nobody would have to worry about it again.

With phive being something separate, when a build/sniffer fails; one to work on it, would have to go in, perhaps learn about phive for the first time.

It seems like too much complication to get a sniffer. Isn't there some other way to run the sniffer, something that could be a composer dependency?

[oliverklee]

@danon Thanks for the feedback! I've now changed this from a PHIVE-installed PHAR to a Composer dependency.

[danon]

@oliverklee Would it be possible to only run the sniffer for the declare(strict_types) and for nothing else?

Remember, that we try to make this sniffer, so that we can introduce declare(strict_types) convention, (as of #16).

[oliverklee]

@danon Currently, the sniffer indeed only sniffs for the strict types, and for nothing else. :-)

So after this PR and #16 are merged, I can add the sniffer to the CI build.

(I'll add sniffing for PSR-12 later when all PSR-12 issues are resolved.)

[oliverklee]

@danon Is this ready to review, or do you still need anything from me for this PR?

[danon]

@oliverklee I will review this today afternoon. Thank you for your help. If I don't find anything, I'll rebase the PR, if I do i'll write in this PR :)

[oliverklee]

@danon Do you still need anything from me so you can merge this PR? (I'd like to reduce the number of open PRs as I rebase all of them after one has been merged, and some PRs also depend on other PRs.)

[danon]

@oliverklee I only have one question.

Why do we need two tools? Php_CodeSniffer and PhpStan?

Couldn't all our needs be solved by just one of them?

[oliverklee]

Why do we need two tools? Php_CodeSniffer and PhpStan?

Couldn't all our needs be solved by just one of them?

No, they focus on different things and have only a very small overlap concerning the issues each tool can find.

For example, PSR-12 style checking is a CodeSniffer-only thing, while data flow analysis with type compatibility check is a PHPStan-only thing. (And checking for the strict types declaration at the top of each PHP file also is a CodeSniffer-only thing.)

[danon]

@oliverklee ok, so can we do the PhpSniffer for strict types first? And we leave PhpStan for the second step? :)

[oliverklee]

Yes, we can do it in that order (This first step is what this PR is about).

[danon]

I've pushed the commit into master.