[Split] PHP CS Fixer about component-split

[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.