In these last couple of weeks, I’ve been experimenting with various package managers in an effort to really grasp how they work and assess if package management as a whole would be a productivity booster at my workplace. While this seems like a classic case of the D.U.H. for Ruby, Node.js or Python folks out there, as a PHP guy in an agency, this is rather new to me.

I’ve fiddled with RubyGems and NPM for the last couples of years now, but never in the context of building an app. For example, I’ve used SASS to build better stylesheets, I’ve used LocalTunnel to test websites on mobile devices, I have tested LiveReload to accelerate front-end development. But none of these packages made it in an actual app as a library; they were rather tools that helped me build and test my projects. So I started looking at how and why we should start doing this at work in a very PHP/CSS/JS driven environment.

With PHP having such a low-entry barrier, it usually gets bad rep for having a disorganized community and probably the most diverse types of users (absolute non-programmers that fiddle with HTML once in a while to veterans of the Web industry). Composer kinda proves, for me at least, that this language is still alive and stronger than ever. Most major frameworks are represented on Packagist and more packages are added every day. For us, it would make a lot of sense to keep our repositories to a minimum and download dependencies apart from the rest.

On the frontend side, Bower makes an excellent job at covering most libraries. NPM provides all the necessary Grunt plugins to optimize images, render screenshots, concatenate and minimize stylesheets and scripts and so much more.

I have yet to figure out how we will integrate all of these technologies in our day-to-day workflow but I strongly believe this year will be the year of package management for us.