Recent years have seen the proliferation of high-quality package management tools for a wide range of web development languages. Ruby’s gems were always a key selling point of that platform, allowing for a sort legendary developer productivity which is now, thankfully, widely available regardless of platform.
But dependency management is an art unto itself, one that many give little thought to until something breaks catastrophically, leaving developers scrambling to patch some obscure dependent module they didn’t even know they had, as the left-pad debacle did for Node.js developers earlier this year.
If, as developers discovered that day, your project is only as strong as your weakest dependency, it’s prudent to have a handle on what you’re pulling in, from whom, and how you’re doing it.
Big names like Facebook were caught off-guard as everyone else, and the desire to be in control of their dependencies has doubtlessly led to the creation of yarn, a new JavaScript package manager, which we, too, are very excited about.
Operating alongside npm, meant as a drop-in replacement, Facebook touts the following benefits:
- Speed
- Reliability
- Security
The latter two benefits are tied to a .lock file, something that PHP users of Composer are likely familiar with, but which npm lacks:
The magic clue behind it? Whenever you run
yarn install, theyarn.lockfile has precedence over thepackage.json.
If the
yarn.lockfile exists, the (exact) versions defined in it will be used.
If no
yarn.lockexists, the (loosely defined) versions defined inpackage.jsonwill be used, and ayarn.lockis generated.
Package management on the PHP side seems comparatively safe and manageable. PHP has an extensive standard library, and we’re unlikely to pull in 100 packages to boot a simple application. It’s much easier to survey the landscape of an application’s dependencies and get a feel for what’s there and why it’s there.
Features that yarn aims to bring to the table for JavaScript developers, such as that lock file, have always been part of our workflow. So, perhaps you haven’t thought about it too deeply.
In fact, you might have questions which are worth reviewing.
Why the composer.lock file matters
How precisely does it relate to composer.json? Should I commit it to version control? How do I manage conflicts?
Managing PHP Dependencies Properly
What should I pull in as a dependency, and what as a dev dependency? Should I need to modify a dependency, what’s the correct way to go about it? How do I optimize my package usage for production?
Above all, be mindful of what you pull in, what that which you pull in pulls in, and the faculties your toolchain offers to allow you to manage these, lest today’s convenience lands you in an uncomfortable situation down the line.
