Plugin-php: Usage on active code base

Created on 7 Mar 2018  路  8Comments  路  Source: prettier/plugin-php

I have a question. I've got a medium-ish code base (100-150 KLoC) and have been looking for a solution just like this. My goal is to get all our PHP code prettified automatically before it even gets pushed up to our repository. I ended up here because I have a similar need for our Typescript code base, and was very happy to find that prettier can do both.

Do you know if anyone is actively using prettier on production code? Obviously your readme file warns against doing that, but (other than #173 ) my initial tests don't show any stoppers. Obviously I'm not going to just run prettier and throw things up to production. We have good unit test coverage and all commits go through code review, so if prettier breaks something I'm confident that we'll find it long before production breaks. Obviously I would do plenty of testing before actually putting in a pre-commit hook. My question for you is therefore this: do you feel like this is approaching a point where it can be tested on an active code base? If so, I'm happy to be part of the experiment.

Most helpful comment

@mgrip I just ran it through on some subdirectories in my project and created issues accordingly. I ran it through about 30K lines of code total, and only came up with a couple breaking issues. That sounds pretty darn good to me. At this point I was just focused on breaking changes - I didn't look through the output searching for anything that might be considered a formatting bug.

All 8 comments

Hi @cmancone,
I don't think anyone is using this plugin on production code yet - I'd actually doubt that it's used much at all right now. However, we did make a lot of progress in the lasts weeks and I think we're about to reach the point where we're not breaking anything anymore.

When this is done, we can release a alpha version that can be used by early adopters. There will be many formatting-related edge cases to fix until we can release something stable.

I think our first priority is to fix anything that breaks code, and we'd love your help on this by testing it in your code base! Also feel free to open any issues if you see some strange formatting. I think everyone contributing here is as excited as you are to start using this on his or her codebase :wink:

@cmancone one way to try out on your codebase and make sure you wouldn't be breaking anything is to run with the --debug-check flag. This basically does a comparison ast(print(ast(input))) === ast(input) to make sure that the printer isn't breaking anything. If you run that on your codebase ie

prettier some/directory/*.php --debug-check

and see any breaking issues please let us know by creating a new issue!

@mgrip I can find some directories to run that on that don't run into the array destructor issue and report back sometime this week. Thanks!

@mgrip I just ran it through on some subdirectories in my project and created issues accordingly. I ran it through about 30K lines of code total, and only came up with a couple breaking issues. That sounds pretty darn good to me. At this point I was just focused on breaking changes - I didn't look through the output searching for anything that might be considered a formatting bug.

@mgrip So just to rehash, I found very few breaking issues in my code base so far. Just #173, #210, and #211 (some of which had already been reported here in different forms). However, all of those ultimately track down to issues in the underlying PHP parsing library, and they can't get fixed here until they get fixed there. One of them has been an open issue in the PHP parsing library since late December. Is that about right?

Who do we have to bribe to get them moving :)

@cmancone actually @ichiriac is already moving at a quite impressive speed, just take a look at the recent commits: https://github.com/glayzzle/php-parser/commits/master
I think that we'll reach the state where there are no breaking issues left anymore very soon!

On a side note though: If i find the time in the coming weeks, i'll try to dig into the codebase of the parser a bit. It would be great if the maintenance of the parser is not resting on the shoulders of a single person. If anyone else sees this the same way, you know what to do :wink:

@czosel, @mgrip, and @evilebottnawi just have to say: I'm impressed by all of your progress. Sorry I haven't had time to try to contribute code myself! I pretty much run it through my code base with each update, and everytime I do, the bugs found are more and more obscure edge-cases. At this rate things will be ready to go in no time!

Let's close this issue, looks we already fix a lot of problems, other problems should have own issue

Was this page helpful?
0 / 5 - 0 ratings

Related issues

aboyton picture aboyton  路  4Comments

bertuz picture bertuz  路  5Comments

czosel picture czosel  路  4Comments

mgrip picture mgrip  路  3Comments

nikulis picture nikulis  路  5Comments