Starting a New PHP Package The Right Way

Originally published at: http://www.sitepoint.com/starting-new-php-package-right-way/

This entry is part 1 of 1 in the series How To Build Your Own PHP Package

How To Build Your Own PHP Package

  • Starting a New PHP Package The Right Way

Back when we covered Diffbot, the visual AI-enhanced machine-learning crawler, we also mentioned they have libraries for a wide array of programming languages, but those are often less than cutting edge ā€“ with so many to keep an eye on, thereā€™s bound to be a few bad apples that slip through the cracks. One such apple is the PHP library, and weā€™ll be building an alternative in this series, in an effort to do it better.

Note that this tutorial will focus on writing a good package ā€“ the code we write will be real and production-ready, but you shouldnā€™t focus too much on Diffbot itself. Diffbotā€™s API is simple enough and Guzzleā€™s interface is smooth enough to just consume it outright without the need for a PHP library anyway. Rather, pay attention to the approaches we use to develop a high quality PHP package, so you can reuse them in your own project. Diffbot was selected as the subject of the package because Iā€™d like to demonstrate best practices on a real world example, rather than yet another ā€œAcmeā€ package.

Continue reading this article on SitePoint

1 Like

Just a quick response to your improved gitignore fork: its a common rule to leave your IDE,OS specific artifacts in your local global ignore file so you donā€™t clutter the ignore file with your specific environmentā€¦

Looking forward to the rest of the series!

Yes, Iā€™ve talked about this with League, and they were actually surprised at my Git setup. Iā€™m a bit particular in regards to that in that I donā€™t have a global Git - I use Git from within the VM exclusively. This makes sure my entire setup is in the VM and the VM alone, making it 100% portable to any and all machines I come in contact with. I know most people donā€™t work that way, but it works wonders for me. Thanks for the feedback!

Thats another thing iā€™ve been wondering about: why work inside the VM like that? With tech like docker (which I personally use extensively, even inside PHPstorm) i have the very best of performance and still have a clean development machine.

(i.e. no PHP install on my dev, but Iā€™ve mapped my PHP executable in PHPstorm to a docker run command. This too for CodeSniffer which is in comparison with locally installed PHPCS negligibly slower without the hassle of version conflicts per project etc Currently we run Grunt, NPM, PHPCS, Bower, PHP, PHPUnit all from docker :+1: )

But back on topic: why not add those to a global gitignore in the VM then? Iā€™d rather see you illustrate the best way and explain why then to go against such a commonly accepted method ( https://github.com/github/gitignore / http://augustl.com/blog/2009/global_gitignores/ )

Docker is great, when youā€™re not working with Windows. I, however, am.

Windows is my host machine, and keeping Git and related tools up to date on it is a pain. Keeping my configuration inside the VM keeps all my development efforts 100% separate from the host, meaning I can not only rely on the VM to have the most up to date tools I need at any time on any machine, but also that I can just grab the vagrant folder and take it somewhere with me.

If I were able to run docker on Windows without a middle-step like boot2docker or similar, then yes, things would probably look different. But when I take into consideration the various OS differences, I come to the conclusion that the average effort to get started is lowest when using this approach of mine. Thatā€™s not to say this isnā€™t to change as the technologies evolve, but currently, this is the setup Iā€™ve found works instantly and trouble-free for the greatest number of people. Iā€™ve yet to see any complaints about it.

You are right, however, that these should be added to the global gitignore inside the VM. I will make an effort to do so in the next release of Homestead Improved, thanks for the suggestion.

Hi @swader,

I had a look at the cool things The PHP League has done. I especially looked at their League\Csv package and it is indeed very nicely coded - really inspiring.

However, I noticed that it took more than 6 months of commits to take it where it is now. I honestly feel that it is unrealistic to think that any real life project will allow for that much time to develop one module, one tiny part of a project.

My point is that it will be very hard to implement such strict standards inside commercial PHP products when dealing with economics more than with standards.

What do you guys think ? Maybe I just havenā€™t (yet) met the right clients ?

Run phpcs with SF2, a lot of ERRORs from the auto-generated stuffs (Entity/*, for example).

Well, you shouldnā€™t wait for League packages - just pick those you like and use them, no? Or did I miss your meaning? Standards are very easy to implement when done from scratch - just set your IDE to use them and youā€™ll never stray. Donā€™t allow other devs not to use them, and your team is automatically in sync.

I have to agree about using a VM on Windows. Someone much smarter than me also pointed me to PuPHPet, Vagrant and Virtualbox and wow, what a difference. I will never go back to using Windows for the server environment again.

Scott

1 Like

I canā€™t even imagine myself developing on bare Windows any more, no matter how many packages exist to make things simpler. Vagrant has drastically changed the way I develop.

1 Like

Yes, all one needs is a halfway decent computer with a bit of extra RAM and away we go! :smiley:

Scott

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.