Meet Jordan Harband: he currently maintains more than 200 npm packages.
Jordan’s foray into the world of open source began serendipitously. His first job was as a social worker in a group home, but he soon realized it wasn’t possible to raise a family in the Bay Area on a social worker’s salary.
So he switched gears and focused on his other passion, which was programming, and used those skills to help start a company called MixMatchMusic in 2006 out of the CEO’s family garage. It was originally a music collaboration and remixing community, then morphed into a phone app.
How to become a maintainer
Though MixMatchMusic was moderately successful, it never totally took off, so he started working as an engineer at a company called BrightKite in 2010. That’s when he submitted his first pull request to fix a bug in a jQuery plugin, and his work as a maintainer began.
“Over time I would fix bugs and things,” Jordan said, “and a lot of maintainers will be like, ‘Here, you do it,’ and I’d take over a project, because the maintainer wanted help.”
“Once a polyfill is fixed and working you don’t have to touch it much,” Jordan said. “With polyfills, I don’t need to entertain feature requests.”
A systematic approach to maintenance
For the projects he maintains that aren’t polyfills, like a query string parser called qs, he fields many feature requests because everyone has a certain format that they would like to work. In cases like these, Jordan has a systematic approach to maintenance, which helps him keep his code healthy.
“There’s an art to envisioning in advance which abstractions are going to scale to more use cases and require less breaking changes,” Jordan said.
Besides filtering feature requests, Jordan tries to support a wide range of compatibility. This means for something like his qs project, he applies any new changes to almost every older release stream.
“My philosophy is to make it as easy as possible to upgrade to the newest versions of their dependencies,” Jordan said. “I don’t want my stuff to ever be the reason something is harder for people to upgrade. The slightly increased maintenance cost on small packages is really worth the objectively larger amount of pain that will be caused to other people if I don’t do that.”
The more dependencies the better
He’s also a firm believer in small, single-purpose modules, which is sometimes a controversial viewpoint.
“I think strong, separate modules, with more dependencies are better,” Jordan said. “It’s not overkill to make a separate one- or two-liner.”
Jordan cites the left-pad debacle as an example. Quick refresher: in 2016, a maintainer unpublished all of his 200-plus modules from npm, which resulted in millions of broken builds and failed installations.
A lot of people thought it was overkill to make a separate package for a functionality left-pad provided. However, because of Jordan’s work on the padStart proposal for TC39, he had found bugs in every potential left-pad replacement he’d found online.
“But if you write an independent module, and you do it well,” Jordan said, “you’re gonna test all possible inputs to your function and therefore if someone uses it in a way you don’t intend, you cover it. You can’t misuse it.”
Jordan’s process for writing quality code includes writing thorough tests, having lots of people review it, and getting lots of people using it. These processes make it possible for Jordan to maintain as many packages as he does, and feel confident that most of his modules will remain bug-free.
And if there’s a bug, he said, he’ll fix it. But he’s confident there won’t be many bugs.