I was recently talking with a friend about all of the available tools that are on the market for us today (some free, some open source) that help us with our development needs.

Modern Package Managers: Yarn

These include things like:

Of course, each of the above is not necessarily comparable because some are front-end tools, others are backend tools, and there are some that offer a hybrid of sorts.

Further, some are premium, some are open source, some appear to be abandoned, and some have even lead to broken build processes.

This leads to a series of questions several of which I’d like to cover. So here, if nothing else but musings on modern package managers, are the things about which I’ve been thinking.

Modern Package Managers

The questions that came to mind for me (and that I was discussing with said friend) are as follows:

  • how are we supposed to know which to use,
  • when to use them,
  • and if it’s worth sticking with them?

And so I thought I’d share my current thoughts on said tools and their applicability here.

Which Ones Do We Use?

It’s easy to shirk this answer and say “whichever one you want,” but I think the answer is a bit more nuanced than that.

For example, there are learning curves, packages, maintenance, and so on that come with each of them. This isn’t a good or a bad thing – it’s the natural of what they are.

Modern Package Managers: Composer

The question I am more interested in asking is “which one serves my team, my project, and my customers best?” And here’s why:

  1. If the team can easily adopt the utility, then there’s next to zero friction for getting up and running with it for their work.
  2. If it works well with the project from the outset, then it should ease maintenance as a project grows and matures. This is important because otherwise we risk wasting valuable time and effort to get things up to speed when the utility changes (if it changes) and this can be detrimental to a schedule for a project.
  3. What serves the customer best, I believe, is one of those “the devil is in the details” situations. That is so that if the first two are satisfied, the customer will be none-the-wiser. Secondly, it would cost less time, provide more value, and keep them invested in using you as a vendor for their service.

That said, I don’t believe there’s a single “This is the utility that you should use” case because, again, I don’t know the details of a given project. Thus, I don’t want to prescribe one solution when another may fit the case.

And here’s an example:

I’ve used Gulp, CodeKit, and Yarn all in different projects. Would it be nice to have a single tool to use? Sure! And each one can do relatively the same things as the others.

But the speed at which it takes to get something going, the portability and available packages slightly differ, and if I’m working on something for myself, for a customer, with a team, or alone are all factors that work themselves into the equation.

Overtime, I believe that we develop an intuition about which one may be best given the requirements of a project and given experience with each of the tools above.

So, sure, there’s some investment up front that’s required to become familiar with however many you see fit to be beneficial to your team and efforts, but it can serve you well as you continue to move forward as a developer.

When Do We Use Them?

I don’t think that this is as difficult a question to answer if you’ve done your due diligence on trying them out. Again with the intuition, right?

Modern Package Managers: CodeKit

But here’s my general approach:

  • If I’m working alone or I need to focus on something quickly, CodeKit is a good solution.
  • If I’m working with a team and need to have something fast, scalable, and well-defined, Yarn is a good choice.

I still think Gulp is worth taking a look at using but development and packages for it seem to have slowed. Grunt doesn’t appear to be in development at the moment, but if it works for you and the packages you need, it may not be worth changing right now.

In fact, I’d say unless you can provide a solid reason for changing, then why bother? Practicality matters.

Is It Worth Sticking With Them?

I don’t know. I mean, technology moves so fast, and new tools come in (which I don’t necessarily think we should always adopt), and then they stick around for a while.

Modern Package Managers: Musings

Perhaps they stagnate. Perhaps they do not reach widespread adoption. Perhaps they are retired.

Maybe the most optimal answer to this question is to find out what will help you solve the problem in the most efficient way possible, that is also being supported by an active community of developers, and that you and your team can most easily adopt?

The Bottom Line?

If anything, this post is nothing more than personal musings on how to approach the ever-changing landscape of build tools and package managers. And it’s how to reason through when to which one given a certain type of problem.

I don’t necessarily want a single solution because I think the options we have foster more innovation. At the same time, it can introduce a level of fatigue when you have to keep up.

So, if nothing else, examine a subset of the most popular tools (perhaps as starred on GitHub as a useful metric) and then go from there.