prettier / plugin-php

Prettier PHP Plugin

Prettier PHP Plugin

Intro

Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary.

This plugin adds support for the PHP language to Prettier.

Can this be used in production?

We're considering the plugin to be stable when pure PHP files are formatted. Formatting of files that contain mixed PHP and HTML is still considered unstable - please see open issues with the tag "inline" for details.

If you want to use the plugin in production, we recommend limiting its scope to pure PHP files.

Input

<?php
array_map(function($arg1,$arg2) use ( $var1, $var2 ) {
    return $arg1+$arg2/($var+$var2);
}, array("complex"=>"code","with"=>
    function() {return "inconsistent";}
,"formatting"=>"is", "hard" => "to", "maintain"=>true));

Output

<?php

array_map(
    function ($arg1, $arg2) use ($var1, $var2) {
        return $arg1 + $arg2 / ($var + $var2);
    },
    [
        "complex" => "code",
        "with" => function () {
            return "inconsistent";
        },
        "formatting" => "is",
        "hard" => "to",
        "maintain" => true,
    ]
);

Playground

You can give the plugin a try in our playground!

Install

yarn:

yarn add --dev prettier @prettier/plugin-php
# or globally
yarn global add prettier @prettier/plugin-php

npm:

npm install --save-dev prettier @prettier/plugin-php
# or globally
npm install --global prettier @prettier/plugin-php

Activate the plugin

Create or modify your prettier configuration file to activate the plugin:

{
  "plugins": ["@prettier/plugin-php"]
}

Use

With Node.js

If you installed prettier as a local dependency, you can add prettier as a script in your package.json,

{
  "scripts": {
    "prettier": "prettier"
  }
}

and then run it via

yarn run prettier path/to/file.php --write
# or
npm run prettier -- path/to/file.php --write

If you installed globally, run

prettier path/to/file.php --write

In the Browser

This package exposes a standalone.js that can be used alongside Prettier's own standalone.js to make the PHP plugin work in browsers without a compile step.

First, grab both standalone scripts from an npm CDN like unpkg:

<script src="https://unpkg.com/prettier/standalone.js"></script>
<script src="https://unpkg.com/@prettier/plugin-php/standalone.js"></script>

Then use Prettier with PHP, just like this:

await prettier.format(YOUR_CODE, {
  plugins: prettierPlugins,
  parser: "php",
});

See this code in action in this basic demo.

With Bundlers

Bundlers like webpack, Rollup or browserify automatically recognize how to handle the PHP plugin. Remember that even when using a bundler, you still have to use the standalone builds:

import prettier from "prettier/standalone";
import * as prettierPluginPhp from "@prettier/plugin-php/standalone";

await prettier.format(YOUR_CODE, {
  plugins: [prettierPluginPhp],
  parser: "php",
});

Configuration

Prettier for PHP supports the following options. We recommend that all users set the phpVersion option.

Name	Default	Description
phpVersion	"7.0"	Allows specifying the PHP version you're using. If you're using PHP 7.1 or later, setting this option will make use of modern language features in the printed output. If you're using PHP lower than 7.0, you'll have to set this option or Prettier will generate incompatible code.
printWidth	80	Same as in Prettier (see prettier docs)
tabWidth	4	Same as in Prettier (see prettier docs), The default is 4 based on the PSR-2 coding standard.
useTabs	false	Same as in Prettier (see prettier docs)
singleQuote	false	If set to "true", strings that use double quotes but do not rely on the features they add, will be reformatted. Example: "foo" -> 'foo', "foo $bar" -> "foo $bar".
trailingCommaPHP	true	If set to true, trailing commas will be added wherever possible. If set to false, no trailing commas are printed.
braceStyle	"per-cs"	If set to "per-cs", prettier will move open brace for code blocks (classes, functions and methods) onto new line. If set to "1tbs", prettier will move open brace for code blocks (classes, functions and methods) onto same line.
requirePragma	false	Same as in Prettier (see prettier docs)
insertPragma	false	Same as in Prettier (see prettier docs)

Ignoring code

A comment // prettier-ignore will exclude the next node in the abstract syntax tree from formatting.

For example:

matrix(
  1, 0, 0,
  0, 1, 0,
  0, 0, 1
);

// prettier-ignore
matrix(
  1, 0, 0,
  0, 1, 0,
  0, 0, 1
);

will be transformed to

matrix(1, 0, 0, 0, 1, 0, 0, 0, 1);

// prettier-ignore
matrix(
  1, 0, 0,
  0, 1, 0,
  0, 0, 1
)

Editor integration

Atom

The official prettier plugin for atom supports plugins.

Visual Studio Code

The official prettier plugin for vscode supports plugins since Version 1.10.0. To enable it, install the extension and make sure the plugin is installed locally (in your project folder).

Visual Studio Code may not recognise the document selectors provided by this plugin, and so you can add php to your document selectors by adding the following line to .vscode/settings.json:

  "prettier.documentSelectors": [
    "**/*.{js,jsx,ts,tsx,vue,html,css,scss,less,json,md,mdx,graphql,yaml,yml,php}"
  ]

You may also need to declare php as the parser in your prettier config file:

{
  "parser": "php",
  "plugins": ["@prettier/plugin-php"]
}

See (this issue)[#1730] for more discussion around potential VS Code solutions.

PhpStorm / IntelliJ / Jetbrains IDE

• Install prettier and plugin locally yarn add -D prettier @prettier/plugin-php
• Open Settings (File, Settings)
• Go to Plugins Section, Select Marketplace, Search for Prettier, Install Plugin, Restart IDE
• Open Settings, Search for Prettier, select Prettier in left settings navigation
• Check prettier package has auto-detected, should be something like myproject/node_modules/prettier
• Update Run for Files to include .php, eg: {**/*,*}.{js,ts,jsx,tsx,php,json,scss,vue,md}
• Tick the On Save button, if you want your files formatting updated on file save
• Clock OK to save settings

Note: Just pressing save does not reformat your current file unless the file has been modified in some way, alternatively you can use the Prettier shortcut Ctrl+Alt+Shift+P

Sublime Text

Sublime Text support is available through Package Control and the JsPrettier plugin.

Vim

Regarding plugin support in the official plugin vim-prettier see this issue.

ALE

The linting plugin ALE has built-in support for prettier and its plugins. Just add prettier to your list of fixers. For example:

let g:ale_fixers={
  \'javascript': ['prettier'],
  \'json': ['prettier'],
  \'php': ['prettier'],
\}

Custom

Alternatively, adding the following to .vimrc will define a custom command :PrettierPhp that runs the plugin while preserving the cursor position and run it on save.

" Prettier for PHP
function PrettierPhpCursor()
  let save_pos = getpos(".")
  %! prettier --stdin --parser=php
  call setpos('.', save_pos)
endfunction
" define custom command
command PrettierPhp call PrettierPhpCursor()
" format on save
autocmd BufwritePre *.php PrettierPhp

Integration for other tools

PHP-CS-Fixer

See docs/recipes/php-cs-fixer for integration help, code can also be found in https://gist.github.com/Billz95/9d5fad3af728b88540fa831b73261733

Contributing

If you're interested in contributing to the development of Prettier for PHP, you can follow the CONTRIBUTING guide from Prettier, as it all applies to this repository too.

To test it out on a PHP file:

• Clone this repository.
• Run yarn.
• Create a file called test.php.
• Run yarn prettier test.php to check the output.

Maintainers

Christian Zosel

Evilebot Tnawi

plugin-php's Issues

include form

require ('somefile.php');

vs

require 'somefile.php';

All popular framework use this form:
https://github.com/laravel/framework/search?l=PHP&q=require&type=&utf8=%E2%9C%93
https://github.com/symfony/symfony/search?utf8=%E2%9C%93&q=require&type=
https://github.com/yiisoft/yii2/search?l=PHP&q=require&type=&utf8=%E2%9C%93

Vote welcome.

1. ❤️ - First example
2. 👍 - Second example
3. 💯 Output as is

`break` statements stripped of optional number

I've created a new branch (nikulis/prettier-php@7ee8034) to address this, but did not want to PR at the moment since it is based on the already-open #14.

---

The php break statement should accept an optional trailing integer denoting the number of nested control statements to break. Currently, any trailing integer is removed.

Input:

<?php

while(true) {
  while(true) {
    break 2;
  }
}

Current output:

<?php

while(true) {
  while(true) {
    break;
  }
}

---

There are a couple other quirks surrounding the use of the break statement that may or may not fall under the purview of this project to auto-correct and/or offer configurable parameters for:

1. Apparently, php also allows for parentheses around the trailing integer, making it look like a function call, e.g. break(2);. Could we automatically remove the parentheses so that all breaks follow the same convention?

2. break 1; could be collapsed to break;.

Comments with /****** are broken

This

/*********************
 * Some long comment *
 *********************/

is transformed into

// ********************
 * Some long comment *
 ********************

Function type hints

input:

function type_hinting_test(array $test, int $int_test, string $string_test = '') {
    return $int_test;
}

output:

function type_hinting_test($test, $int_test, $string_test = '') {
    return $int_test;
}

Line spacing within files

Make sure that when printing code there’s at most one empty line in between lines and none at the beginning or end. We should hopefully be able to reuse the same logic implemented in the JS printer

@prettier/plugin-php not found in the registry

Right now, the name of the npm lib is @prettier/php.

Thank you for your work!

Strategy on adding new options

I think we should discuss the general procedure on how we handle the wish to add new options.

I started writing this as a comment to #118, but I'd like to discuss the "big picture" in a separate issue instead.

To me, #118 is a nice example to prove @evilebottnawi 's point in the discussion about opening braces (#107, #108):

I'm not against the option or not specifically this option, the only problem is that adding one option other will want more options, and each will complicate the maintenance of the project and deliver only problems

In this case, I'd advise against introducing a new option, because the number of options we'd have to support if we allow configuration of "this type of" styling decision.
Thinking about it from this standpoint, I'd even support your wish to revert the option we introduced about curly braces and add it back in when we've released a first stable version and the tool has been in use for a while - because then we have an actual community of user that will keep asking for specific options.
I'd also like to cite two comments by @vjeux which might offer guidance:

For prettier, I used a combination of my experience writing JavaScript for 10+ years, grepping through the millions of lines of the Facebook codebase to see which style was more popular, reading through various coding styles (eg Airbnb) and what are all the related eslint configs and finally feedback from people complaining that some pattern looked bad.
My guiding principle was for the code generated by prettier to pass code review as if it was written by a human. I also tried to make all the decisions be as less controversial as possible.

Also, one thing that really helped is to have someone to make the final decision. This way all the discussions could happen and were useful input but at the end of the day, only the things I wanted would go through.
I found that there are a handful of useful tactics to manage those discussions:

• Ask for specific snippets of code and try to find solutions for those. So many times people argue about very general things but in practice there are concrete fixes you can do for their use case.
• Explicitly say that you're not going to make a decision right now on certain issues. One thing that people pick up quickly is to engage in places where the people involve the project are responding. Then once in a while you can sort issues by upvote/comments and figure out what are the most painful things and do a deep dive.
• Avoid style trashing. Ideally, you should think deeply about each important style decision you are making and once you do it, actually commit to it. This way you can "close" the issue and whenever this subject comes up in the future say that you have reached a decision and are not looking to spend time thinking about it for now. This way you can focus on the things that still need to be fixed rather than going through the same discussions over an over again wasting everyone's time. This is hard to do in practice but if you can pull it off, it'll help a lot.

(See #59 (comment))

I'm gonna make a suggestion on how i could imagine we handle things, just to keep this issue actionable:

• Until our first release, we don't add any custom options and remain PSR-2 compatible.

After that:

• We only consider a new option if there is a considerable amount of requests to add it
• If necessary, we put the decision up to a vote after a short "cool-down" period

That would also mean that we don't open anything that involves adding options for votes just yet. Of course we can (and should) vote on difficult stylistic decisions that go into the first version.

What do you think?

/cc @mgrip

Curlys in encapsed strings

Curlys in encapsed strings are not fully supported yet ("two {$b}s" vs. "two ${b}s";).

See glayzzle/php-parser#101

PSR-12 compliant function call wrapping

Quoting @nicoder:

As far as I can tell, both are PSR-2-compliant, and PSR-12 adds precisions because there was debate about that:

https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md#47-method-and-function-calls

for example PSR-12 lists this is valid:

$app->get('/hello/{name}', function ($name) use ($app) {
    return 'Hello ' . $app->escape($name);
});

but this would not be :

$app->get('/hello/{name}',
    function ($name) use ($app) {
        return 'Hello ' . $app->escape($name);
    }
);

I understand it this way:

• if one argument is defined starting on a new line, then all of the arguments must start on their own line
• but arguments may take up more than one line (independently of whether they start on their own line or not)

For example it may be nicer to see:

foo([
   $longExpression,
   $prettyLongExpression,   
]);

than:

foo(
    [
       $longExpression,
       $prettyLongExpression,   
    ]
);

Or nicer to see:

$db->Execute($sql, [
    $foo,
    $somewhatLongParameter,
]);

than:

$db->Execute(
    $sql,
    [
        $foo,
        $somewhatLongParameter,
    ]
);

implement return types for methods

input:

function returnTypeTest(): string {
  return 'hi';
}

class Test
{
  public function returnTypeTest(): string {
    return 'hi';
  }
}

output:

function returnTypeTest() {
  return 'hi';
}
 
class Test
{
  
    public function returnTypeTest()
    {
       return 'hi';
    }
 }

Option for opening brace

1st off I want to be clear - I think the default should still be to follow PSR2-like formatting standards

With that in mind, from my own experience and now starting to look through other open-source php projects, it seems like one of the biggest differences in formatting standards is putting the opening brace for functions, classes, etc on a new line vs same line. I'm a little worried that not having this option might scare people off from using prettier/plugin-php.

I was thinking of starting to work on a PR for adding an option to do this (defaulting to the PSR2 format of putting it on a new line), but wanted to open for discussion first.

openingBraceNewLine = true (default)

class Test
{
  public function testMethod()
  {
  }
}

function testFunction()
{
}

openingBraceNewLine = false


class Test {
  public function testMethod() {
  }
}

function testFunction() {
}

SyntaxError: Unexpected token after install

Having installed prettier and @prettier/plugin-php globally, I cannot seem to get prettier to work on any php files, it always results in a syntax error.

Am I doing something wrong?

implement continue node

https://github.com/glayzzle/php-parser/blob/master/docs/AST.md#continue

Convert die to exit?

After resolve glayzzle/php-parser#117 we can output die and exit. Should we output always exit as good pretty practice or not?

Reformating chaining

Same here, I can understand why it made that, but I think this is not a good idea:

-        Route::prefix('api')
-             ->middleware('api')
-             ->namespace($this->namespace)
-             ->group(base_path('routes/api.php'));
+        Route::prefix('api')->middleware('api')->namespace($this->namespace)->group(
+            base_path('routes/api.php')
+        );

Use 4 spaces for indendation

To align with the PSR2 standard, we need to use 4 spaces for indentation, rather than 2 (which is happening now). I believe we achieve this by changing the default value for the tabWidth option from 2 to 4. I'm unsure exactly how to override the default value for a global option, from a plugin - @czosel pointed me to prettier/prettier#3924, but I haven't been able to implement successfully yet.

Block comments with incorrect spacing are missing lines

input:

/**
 * Multi line
* test with wrong indentation
*/

output:

/**
 * Multi line
 */

Trailing commas in arrays

I couldn't find anything in the various PSR, but it seems acceptable to add trailing commas to arrays. Thoughts about making this the default?

Multi line comments

input:

// multi
// line
// comment
// test

output:

// multi// line// comment// test

Strip loc when running `--debug-check`

When running prettier with the --debug-check option (for testing), I get a whole lot of ast differences around node locations. I think all this means is that we have to strip out node locations in our ast-clean function? https://github.com/prettier/plugin-php/blob/master/src/clean.js#L5

Function parameters passed by reference

input:

function pass_by_reference_test($x, &$a) {
  $a + 1;
}

output:

function pass_by_reference_test($x, $a) {
  $a + 1;
}

input:

class Test {
  public function test_pass_by_reference(&$x) {
    $x + 1;
  }
}

output:

class Test {
  public function test_pass_by_reference($x) {
    $x + 1;
  }
}

retif missing semicolon

input:

$test ? doSomething() : doSomethingElse();

output:

$test ? doSomething() : doSomethingElse()

Remove comment

I think this one can be pretty hard, but Prettier should not remove comment.

-    protected $policies = [
-        // 'App\Model' => 'App\Policies\ModelPolicy',
-    ];
+    protected $policies = [];

Reformating arrays

I'm not sure about this one, this is just a question of opinion. I understand why it formats the array, but I find it less clear that way.

-    protected $listen = [
-        'App\Events\Event' => [
-            'App\Listeners\EventListener',
-        ],
-    ];
+    protected $listen = ['App\Events\Event' => ['App\Listeners\EventListener']];

Thoughts?

for loops should handle multiple expressions

Examples taken from php docs
input:

for ($i = 1, $j = 0; $i <= 10; $j += $i, print $i, $i++);

output:

for ($i = 1$j = 0; $i <= 10; $j += $iprint $i$i++) {

}

Is this going to enforce PSR-1? PSR-2? What about upcoming PSR-12?

Unlike JavaScript community, PHP has widely adopted code style already that's used by all the major framework vendors. Will this library be implementing those code styles? Or will you guys be doing your own thing?

Currently, PSR-2 (and therefore also PSR-1) is what everyone uses, but PSR-12 is currently under review as a replacement for PSR-2.

function without visibility transform to `public`

Input:

class MyClass
{
    function myFunction() 
    {
        // Nothing
    }
}

Output:

class MyClass
{
    public function myFunction() 
    {
        // Nothing
    }
}

I think it is bug, feedback welcome!

Implementation question: Usage of fastPath

I wanted to tackle #7, so I compared the implementation of the JS and python printers with the PHP one. I noticed that both JS and python rely heavily on calls to path.call, patch.each and so on, for example

https://github.com/prettier/prettier-python/blob/0e5c2a77ceebe2814707b7c61d1d003b1186b564/src/printer/index.js#L125

while in the PHP printer we're usually just calling to the internal function printNode, for example
https://github.com/prettier/prettier-php/blob/cd78cbb906aabeaed8c1e9588d7d89a6e89bae07/src/printer.js#L123

While fastPath seems to be used mostly for performance reasons (please correct me if I'm wrong), the call to print seems important because it calls the core function printGenerically which handles comments, for example.

Does this mean that we should refactor the printer to use path.call, path.each, ...? Since this would be a major change and I guess it should've come up earlier, I thought I'd open an issue before getting started 😉 Thanks!

Remove brackets when composing attribute/methods calls

-        return $this->quantity * $this->{self::PRICE_ATTRIBUTE};
+        return $this->quantity * $this->self::PRICE_ATTRIBUTE;

Helping with testing

I've got a large PHP API codebase that I can run prettier on to help you all test. Can you point me in the right direction for how to do that? Maybe I can add something to the readme.

Don't change \n to an actual newline

First up, awesome work on this project, I'm really excited. I seem to recall there was some discussion about this for JavaScript but I can't find the issue.

Right now this converts

$foo = "hello\nworld"

into

$foo = "hello
world"

Personally I think it is nicer to leave the \n alone.

Remove newlines

Input:

if (version_compare(PHP_VERSION, '7.1.0', '<')) {
    insteria_error('Minimum required PHP version is 7.1.0', 'Insteria Theme Requirement Checker');
}

$autoloaderPath = __DIR__ . '/vendor/autoload.php';

Output:

if (version_compare(PHP_VERSION, '7.1.0', '<')) {
    insteria_error('Minimum required PHP version is 7.1.0', 'Insteria Theme Requirement Checker');
}
$autoloaderPath = __DIR__ . '/vendor/autoload.php';

I think we should newlines as is, it is compatibility with PSR.
Also i'm interested in helping, right now i'm support css/scss/sass in prettier (https://github.com/prettier/prettier/graphs/contributors). You can invite me and i will help to improve output ⭐

Issue template

We need issue template 👍

Remove const public accessor

-    public const PRICE_ATTRIBUTE = 'price_ht';
+    const PRICE_ATTRIBUTE = 'price_ht';

move brace to new line for functions

From #45 (comment)

This came to mind when seeing the output:

The opening brace of a function should be on its own line according to PSR-12 (same as class methods).

(but the opening brace of a closure goes on the same line as the closing parens of the parameter list)

Enable large-scale testing

Now that we've pretty much completed node type coverage, I'd like to keep moving this forward by starting to test some larger open-source projects to uncover outstanding issues. This might already be possible but at least as of now I'm having trouble wrapping my head around how to do that.
@azz @vjeux @czosel does anyone know if this is possible already with the new plugin api/if not what work needs to be done? I'm guessing we'd ideally want to be able to run via the cli with --debug-check enabled on a directory.

Reuse comment logic from prettier

discussion from #71 - investigate if we can reuse the logic from core prettier around comments

missing semicolon when transforming `if` without brackets

if (rand() > 0.5) return true;

becomes

if (rand() > 0.5) {
    return true
}

Pretty output double quotes strings

We have two syntax:

• Easy

$string = "Foo ${bar}";

• Complex (curly) syntax

$string = "Foo {$bar}";

Ref: http://php.net/manual/en/language.types.string.php

Should we:

1. Output encapsed string as is.
2. Output always into complex (curly) syntax.

Chaining wrong

Indentation is wrong when chaining methods and using callables.

Before/after:

     public function jsonSerialize()
     {
-        return collect(parent::jsonSerialize())->mapWithKeys(function ($value, $key) {
-            return [camel_case($key) => $value];
-        })->toArray();
+        return collect(parent::jsonSerialize())->mapWithKeys(
+            function ($value, $key) {
+                return [camel_case($key) => $value];
+            }
+        )->
+            toArray(
+
+        );
     }

Thanks for your work!

Align arrow in arrays ?

I took the habit of aligning all the arrows in a array.
Phpstorm do that automatically, and I find that a lot clearer.

-        'description'  => 'description',
-        'excerpt'      => 'extrait',
-        'date'         => 'date',
-        'time'         => 'heure',
-        'available'    => 'disponible',
-        'size'         => 'taille',
-        'already_paid' => 'déjà payé',
-    ],
+        'description' => 'description',
+        'excerpt' => 'extrait',
+        'date' => 'date',
+        'time' => 'heure',
+        'available' => 'disponible',
+        'size' => 'taille',
+        'already_paid' => 'déjà payé'
+   ]

What do you think about that?

Multi-line conditions

input:

if (reallyReallyReallyLongFunction() && $this->reallyreallyreallyreallyLongMethodName()) {
  return true;
}

if ($this || $that && $theOtherThing && $someReallyReallyReallyLongBooleanVariable) {
  return true;
}

output:

if (
reallyReallyReallyLongFunction() && $this->
    reallyreallyreallyreallyLongMethodName()
) {
    return true;
}

if (
$this || $that && $theOtherThing && $someReallyReallyReallyLongBooleanVariable
) {
    return true;
}

PSR12 specifies:

Expressions in parentheses MAY be split across multiple lines, where each subsequent line is indented at least once. When doing so, the first condition MUST be on the next line. The closing parenthesis and opening brace MUST be placed together on their own line with one space between them. Boolean operators between conditions MUST always be at the beginning or at the end of the line, not a mix of both.

quote escapement removed inside string

$a = "\"";
$b = '\'';

becomes

$a = """;
$b = ''';

Installation package not found

yarn add --dev --exact @prettier/plugin-php
yarn add v1.3.2
[1/4] 🔍  Resolving packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@prettier%2fplugin-php: Not found".

array setting

Before/after

-    protected $fillable = ['title', 'description', 'requester_id', 'type', 'summary', 'proof', 'budget_id'];
+    protected $fillable
+        = ['title', 'description', 'requester_id', 'type', 'summary', 'proof', 'budget_id'];

(actually I don't know if this kind of message really helps you, I'm just reporting all the bugs I'm seeing, but tell me if it's not relevant.)

Missing semicolon when require follows namespace

input:

namespace \test\testing;

require "/test/file.php";
require_once TEST . "/test/file.php";

output:

namespace \test\testing;

require "/test/file.php"
require_once TEST . "/test/file.php"

PSR discussion

I think we should right now resolve this issue, at the moment we are trying to adapt PSR-2, but personally I think this is not quite the right direction. A lot of projects do not fully respect the PSR-(1/2/12) or use its modifications. Other PSR standards may also appear in the future, and they may not be compatible with old PSR. My idea is:

1. The starting configuration does not contain any PSR value, it just makes a beautiful output.
2. We add the option --psr=1, --psr=2, --psr=12 and maybe other value in future.

This will allow projects to migrate easier to the prettier and simplify maintenance. Also use prettier for projects that do not use PSR

/cc @vjeux

Spaces after semicolons in for loops

Currently

<?php

for ($i = 0; $i < 10; $i++) {
    // for body
}

is being turned into

<?php

for ($i = 0;$i < 10;$i++) {
    // for body
}

which seems to go against PSR-12.

Don't add space between `(int)$var`

It seems according to PSR-12 that we should have
(int)$var not (int) $var.

handle references being returned from functions

input:

function &passByReferenceTest()
{
  $a = 1;
  return $a;
}

class Test {
  public function &passByReferenceTest()
  {
    $a = 1;
    return $a;
  }
}

output:

  function passByReferenceTest() {
    $a = 1;
    return $a;
  }
  
  class Test
  {
  
    public function passByReferenceTest()
    {
      $a = 1;
      return $a;
    }
  }