[Split] PHP CS Fixer

[Maks3w]

From @gianarb on April 1, 2015 23:36

Hi!
In your opinion current flow of cs-fix's check is good??
In my opinion this check is not on the same level of the tests failure.

I'm follow this project StyleCI - code || StyleCI - service this is a good idea for a lot of reasons.

• Centralize configuration.. We can manage change of config for all components from single point.
• We can do a different signal if a build failure because a tests is broken or because there is a problem of code style..

In my opinion if I know which PRs don't follow a standard code I can merge them anyway and after a lot of merge I can run CS-fix

Copied from original issue: zendframework/zendframework#7402

[Maks3w]

From @samsonasik on April 2, 2015 6:10

I'm 👍 for it. We can eliminate the .php_cs and php-cs-fixer call in .travis.yml then, right?

[Maks3w]

From @samsonasik on April 2, 2015 6:13

the drawback for it is we still can't exclude folder based on this discussion https://blog.styleci.io/redefining-configuration/#comment-1922515343

[Maks3w]

From @gianarb on April 2, 2015 7:25

Yes but in my opinion this proposal would become more specific, maybe we can extends this flow for other check.. Orchestration of components for the future is a very interesting argument

[Maks3w]

The requirements for the CS tool are two.

• Alert from CS violations
• Provide fix for the CS violation

We want a tool which help the developer to fix the CS violations.

[Maks3w]

From @gianarb on April 2, 2015 9:43

If you are one or more important PRs maybe you can merge a lot of them and
after this process you can apply a CS fix..
I don't know in my opinion this type of check require a different signal :)
But it's my opinion

[Maks3w]

From @gianarb on April 2, 2015 10:41

StyleCI or other server-ci is a very big step maybe in this moment it's too demanding but we can starting from zendframework/coding-standard project to centralize configuration

see doctrine

[weierophinney]

@Maks3w The nice part about php-cs-fixer and phpcs is that they each include tools that allow the developer to fix the majority of problems. This means that they can proactively use the tool to ensure the build passes, or, after a failed build, run the tool to correct the issues.

My personal preference is phpcs, as it covers the entire spectrum of PSR-1 and PSR-2, as well as has relatively easy methods for customizing sniffs. However, the php-cs-fixer lead has been very pro-active in assisting with our project, which has been the deciding factor so far in the use of that particular tool.

We can re-evaluate which tool we'll use after the components are split.