Enhancement: Run PHP_CodeSniffer on Travis

[localheinz]

This PR

• updates .travis.yml to run phpcs on Travis
• adds an XML configuration for phpcs
• removes the dependency on fabpot/php-cs-fixer
• updates README-GIT.md in regard to suggested GIT pre-commit hook, use phpcs instead of php-cs-fixer

Let's see how much pain this is going to cause.

/cc @Maks3w

[danizord]

👍

[localheinz]

Seems like this much pain:

[Ocramius]

Can we remove this? It's a damn pain every second upgrade :P

[danizord]

👍

[localheinz]

Will do after I got up!

[Maks3w]

Two things:

• Only display errors
• Could we have a config file like .php_cs?

[localheinz]

@Maks3w

Doesn't look like the script accepts a config file:

https://github.com/squizlabs/PHP_CodeSniffer/blob/1.5.2/CodeSniffer.php#L2162-L2165

[Maks3w]

May will need to write an XML with the rules for the project.

[Maks3w]

By the moment I've tagged this for next major release just because may add a lot of git conflicts with the PRs in the queue

[localheinz]

@Maks3w

Rebased and updated to use an XML configuration file.

Still failing, of course.

[DASPRiD]

Shouldn't we in the same run also remove the php-cs-fixer abuse as a checker?

[Ocramius]

@DASPRiD yeap

[localheinz]

@DASPRiD @Ocramius

I've also removed the dependency on fabpot/php-cs-fixer and removed the note about optionally adding a Git pre-commit hook.

What do you think?

From what I believe was agreed upon in PHP-FIG ages ago, it would be great to see component maintainers make an effort to get contributors to fix all of these issues. I'm willing to put in some work, too. How about a coordinated effort?

[localheinz]

@Maks3w

Can you provide a list of rules that should be added to phpcs.xml in order to reflect the rules ZF commits to?

[Ocramius]

That is... quite a report :| but I like it a lot!

[Ocramius]

Wondering how much it'd take to fix all those or if we should delay it for when 2.4 is released...

[chadicus]

@Ocramius I opened a PR #6454, but soon realized that PR would be over whelming to review.
Taking @localheinz suggestion I'm separating it per component. Hopefully I'll help take a big chunk out of those 6410 errors.
The first of these is #6490

[Ocramius]

@chadicus I'll start merging those soon.

[Ocramius]

Checked this out locally and rebased it:

--------------------------------------------------------------------------------
A TOTAL OF 6048 ERROR(S) AND 0 WARNING(S) WERE FOUND IN 1042 FILE(S)
--------------------------------------------------------------------------------

So yeah: progress \o/

[Ocramius]

Also see localheinz#2, which includes parallelization of the CS fixes

[Ocramius]

Fair enough. Thoughts, @localheinz?

[keradus]

BTW, when releasing new version I made some regression on Symfony full stack framework and... ZF2 ;)
That's why you see my recent PRs here ;)

[localheinz]

@Ocramius

To me it's not about the tool, but about the results, no? Whichever tool helps to

• fix coding style issues
• enforce the coding style committed to

is a tool that gets the job done.

[localheinz]

Not really related to silexphp/Silex#1079.

[keradus]

Both can do that, and PHP CS Fixer is more mature than PHPCBF.
And looking at community PHP CS Fixer have slightly bigger one.

[localheinz]

--------------------------------------------------------------------------------
A TOTAL OF 4338 ERRORS AND 0 WARNINGS WERE FOUND IN 553 FILES
--------------------------------------------------------------------------------
PHPCBF CAN FIX 3661 OF THESE SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------

Yay!

[keradus]

No need to post same thing in both places:
silexphp/Silex#1079 (comment)
(see last item in list)

[Ocramius]

Taking an opinionated decision and closing as won't fix here.

The reasons behind this change of direction are following:

• @keradus has been quite collaborative, and as a core-contributor to the fixer, he knows his way around php-cs-fixer. I hope he'll stick around :-)
• php-cs-fixer is now stable, and I trust that the stability will be maintained over time
• php-cs-fixer is now a community project, and not just under @fabpot's wing (he obviously currently has no time to look at it closely)
• php-cs-fixer seems to have fixed all the horrible regex-parsing issues by moving to lexer-based parsing of code to be fixed (see Text within strings is changed PHP-CS-Fixer/PHP-CS-Fixer#152) /cc @DASPRiD
• we are using single fixer rules and improving CS checks one at a time, which makes a lot of sense in the diffs, and reduces likeliness of merge conflicts

@localheinz thanks for bringing up the issue though, as we really got very far by just working on this topic! It was really useful to flesh things out :-)

That said, php-cs-fixer will ONLY stay as a build dependency, used ONLY to CHECK if things are wrong: running the fixer on the codebase may still cause unexpected issues, and I want to be very cautious on those.