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

[QWp6t]

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.

[czosel]

In my opinion, it makes most sense to output idiomatic PHP code, which is probably PSR-2 compliant. So no, I wouldn't say we want to do our own thing! 😉
On a side note: I haven't looked at PSR-12 yet - is it very different from PSR-2?

[QWp6t]

PSR-12 is the same as PSR-2 for the most part from what I can tell. It's a little more strict (it has some opinions on things that were omitted in PSR-2, such as more rules within PHP headers), but its primary focus is to create rules for things that didn't exist within the language back when PSR-2 was drafted, such as type hinting and declare() statements.

[theofidry]

@czosel in that case I recommend you to take a look at:

• PHP-CS-Fixer which is used for styleci.io as well
• PHP-CS

It might be worth to leverage one of those in order to achieve what you want, it will likely save you a lot of work.

[MichaelDeBoey]

My vote goes to using PHP-CS-Fixer then 🙂

[czosel]

@theofidry I'm not completely sure if i understand your comment correctly - it was my understanding that PHP-CS(-Fixer) has the same relationship to prettier-php as eslint (--fix) has to prettier - which means that they solve a different problem but can be used together.
Assuming that's correct - how could we use PHP-CS to save a lot of work?

[Narayon]

PHPCS has a built-in beautifier and fixer called PHPCBF.
It follows whatever standard you choose - I'm using WordPress-Extra.
Take a look at vscode-phpcbf extension.

[czosel]

Ok - but PHPCBF doesn't take into account the maximum line length, does it? I guess the whole point of this project is to bring the benefits of prettier powered by Wadler's algorithm to PHP (see also the original blog post announcing prettier)

[theofidry]

it was my understanding that PHP-CS(-Fixer) has the same relationship to prettier-php as eslint (--fix) has to prettier - which means that they solve a different problem but can be used together.

Can you elaborate?

[czosel]

Of course!
ESLint is a linter - it parses your code, and runs a set of linting rules which tell you about possible issues (stylistic or actual errors). ESlint also offers --fix, which can fix the issues it detected automatically (but only for a limited set of rules).
Prettier is different: It's parsing your code into an AST, and reprints the entire file by applying Wadler's algorithm - taking into account the maximum line length.
The "stylistic" rules in ESlint can be in conflict with the way prettier has printed the file - that's why eslint-config-prettier exists: It disables those stylistic ESlint rules, which are taken care of by prettier anyway.

I haven't used PHP-CS much, but I think it is comparable to ESlint.

[theofidry]

So if I understand correctly the goal is the same but the approach is very different:

• ESLint like PHP-CS-Fixer tries to warn/fix the CS issues by applying a set of rules
• Prettier just completely discard the current formatting, just takes the AST and print it again accordingly to its own rules

Is that correct? Assuming it is indeed PHP-CS-Fixer may not be the adequate tool for that job. However PHP-Parser can be of some help: it's the de-factor standard for parsing PHP files into AST. It also includes a formatter which you could use but my guess is that you would rather implement your own formatter.

I tend to find the second approach (AST-based) more robust, but it has a major drawback which is performances: it's way more expansive to parse into AST + print than the token-based approach. But in any case you could also be interested in checking PHP-CS-Fixer cache system which is of great help to avoid applying fixes on only the relevant files

[czosel]

Exactly! (Prettier doesn't completely discard the current formatting, but most of it - there are some cases like line breaks where prettier looks at the formatting of the source file - but those cases are rare and we try to keep the number of them small, because they are making the printing much more complex)

To implement a prettier plugin (like prettier-php), you'll need a parser (preferably written in JS, which is why we use this php parser), and a printer that returns a datastructure which is specific to prettier and it's implementation of Wadler's algorithm - you can see an example here or you can just check the current printer of prettier-php. That's why we can't use any existing formatters.

As for performance, you can take the existing prettier implementation for JS as a reference - it performs quite well (see here)

[mgrip]

A number of recent PR's addressed this to move towards PSR2 (and PSR12) compliance. If you notice specific formatting problems going forward please open more issues, thanks!

[czosel]

@QWp6t That would be great! I agree that right now might be too early - we'll let you know when it's time 😉