Pinning npm packages to y-version?

I noticed we pin packages using the npm caret ranges, which allow packages to be updated to the latest y-version, i.e. 1.2.3 can be updated to 1.3.0. We have seen a few issues related to pulling in new y-versions. These include broken tests, dev environments, etc…

I am wondering if we should move many of our packages to npm tilde ranges and specifically update them when needed. This means they won’t update y-version, but will update z-version. i.e. 1.2.3 will update to 1.2.4, but not 1.3.0.

I know in Foreman’s Gemfile we use a variety of ranges per gem depending on what we need. I wonder if we also be more specific for npm packages?

I don’t know if there are historical reasons to use the caret ranges so apologies if I am missing something. I can see the downside of this approach being that we have to manually monitor and update packages to y-versions, but the upside is we would see less unintended breakages.

Curious to hear everyone’s thoughts.

Slight addendum: I see we already use the tilde range in the package.json in some packages, what I am wondering is should we move most, if not all, packages to the tilde range?

Because of my personal experience with updates in the node ecosystem I would highly suggest to pin versions. I faced the issue several times that even minor updates crashed the whole application.

That’s the downside of this highly modular approach.

One argument I have seen in favor of allowing upgrades to be pulled in is that you spread out the cost of upgrading a dependency over the development cycle rather than taking it all on at once (or never at all). In bastion you can see how we pinned versions and then never upgraded them later on (including libraries that had security vulnerabilities).

I can see the arguments on both sides and would love to hear what others think.

Generally you want to be as open as possible because it gives you flexibility. If libraries properly follow semver then pinning to minor versions should work. Now that’s the theory.

In practice it can be harder. Especially since there are a lot of snaps that essentially test for very exact behavior which can mean you’re forcing yourself to pinning to patch level pinning. Not every library author is as good at following semver.

Without knowing too much of the details I’d suggest to pin to minor versions by default but use patch level when it’s more practical.

1 Like

If we decided to move to stricter version pinning with npm packages, I wonder if a bot like renovate would be helpful? I don’t know too much about it yet, but judging from github issue comments, it seems to be widely used to automate updating package dependencies.

I think the npm stack getting better over the years and those errors get less common.
By definition, y updates mean no breaking changes, the community grows and adopt tools like semantic-release and greenkeeper to solve those issues.
Those problematic npm packages already got marked with a tilde and I’m kind of happy with the way it works.

On the other side I will be happy to see renovate/greenkeeper getting used :+1:

1 Like

Sounds good, I think we can keep an eye out for problematic packages and update their version control to be stricter if needed, it sounds like this is our unofficial policy anyways. Thanks for discussing!