Add PHP support using php-cs-fixer

[jr-cologne]

This PR adds PHP support by making use of the formatting tool php-cs-fixer.

Unfortunately, it does not work yet as php-cs-fixer automatically uses the config from .php_cs.
Because of that, the wanted file in storage/code is not formatted as the specified files from the config file have precedence over the given file in the execution command.
At least, this is what I think is causing that the specified file is not formatted.

To fix this, I have tried to "docker-ignore" .php_cs. However, this does not work either.
In general, it looks like .dockerignore has no effect on which files are copied into the container.

Does anyone have an idea how to solve this or what is actually going on?

[asccc]

the following suggestions are based on my recent pull-request (#27) - which should be merged before this pr, otherwise things will break 😃

we can pass rules as an argument to make php-cs-fixer ignore our php_cs file

[jr-cologne]

Thank you for your help! 👍

[jr-cologne]

Hmm, I'm still getting an error with regards to the php-cs-fixer config/cache files:

stderr: Loaded config default. Using cache file ".php_cs.cache".

Any idea why this is?

[asccc]

The formatter complains, because php-cs-fixer writes stuff to stderr,
I made some suggestions to fix this, but i have not tested them.

The fact that php-cs-fixer used its default config is good, because this means that it did not load our .php_cs file.

[asccc]

Forget what i said. php-cs-fixer does not support stdin/stdout fixing (using pipes).

It supports file-content from stdin, but does not write the result to stdout ... it only supports "diff" ...
We could apply the diff to the content but that would make things unnecessarily complicated.

Instead we could try the php formatter from prettier.
The prettier php-formater is not as sophisticated as php-cs-fixer, but probably good enough™. And to be honest, in most cases, we just want to fix indentations in user provided scripts and not enforce PSR standards to it, because this could lead to situations where users do not recognize their own code anymore 😆

[jr-cologne]

Yeah, ok. I kind of suspected that already.

For the future, it might be a good idea to support both ways of input/output - to a temp file as well as stdin/stdout using pipes.

In #11, @wookiefriseur mentioned that Prettier plugins are way to slow which is why we decided not to use Prettier for formatting PHP.
Of course, we could still try it again.

[asccc]

Since #39 was merged (🎉) we could take look at prettier-plugin-php again.
Maybe the performance is reasonable now?

[jr-cologne]

Yep, I am going to work on that pretty soon.
After merging this PR, I will finally release and deploy a new version to production.

nvm

[jr-cologne]

I think we are good to go. 😃

Prettier is significantly faster than before.
In manual testing, disabling prettierd raised the response time from around 100ms to 700ms.

[asccc]

Nice, this sounds very promising!

[jr-cologne]

Oops, merged it with the wrong title/description as we are not using php-cs-fixer anymore. 😄