How Many Package Managers Should I Support?
Monday, 5 May 2014
For whatever reason, my little hinclude JavaScript library is mildly popular. It’s just a bit of JS that you stick in a page to do declarative includes client-side; mostly, it was an experiment in doing composition a la ESI in the browser. However, Symfony picked it up, and since then, I’ve had a trickle of e-mails, issues and pull requests.
One of those (from Fabio Fabbrucci, who’s contributed a fair amount) was to add a Package.json file, to make it easier to install with NPM, which seemed fair enough; NPM is a JS package manager, and even though it’s mostly for server-side libraries, hinclude could be useful there.
After a while, I added a bower.json file, since I use Bower. Again, Bower is for managing Web assets, mostly JS, and this fit the bill.
Then I got a pull request to add a composer.json file. Apparently, Composer is a “dependency manager for PHP.” I decided to draw a line in the sand, as it were.
Why Not Composer?
I imagine most engineers would add the file and move on. Why don’t I?
First of all, Composer is unabashedly language-specific, and it’s specific to a language other than that of my project! If I add support for it, I have no reason to refuse a pull request to add a package files for Perl, Ruby, Scala and everything else. My little one-file JavaScript project is already a bit heavier than I like.
Secondly, if every project always adds these files, there’s no pressure for consolidation. I want to see the Composer people working with the Bower folks, and whoever else, to come up with a single package format, rather than forcing us to duplicate information so many times - DRY is important, even in packaging.
Pragmatically, I should probably just add the file and move on, but I can’t bring myself to do that. Left to their own devices, I suspect these frameworks will get so diverse and complex that we’ll eventually need a “package manager manager” that creates a set of files based on one meta-configuration file, and we’ll have one more component necessary in our toolchains. And that’s kind of crap.
What do you think? Am I being needlessly obstructionist here?