So here’s the thing – I love Node, and I love the JS ecosystem. I love that there’s nearly always a package for a thing I need (and if there isn’t, I can easily make one).
Ch-ch-ch-ch-changes
The pace of innovation comes at a cost, as these things always do. There are two specific things that bother me in my day-to-day work:
- When I try to pick a package to do a job, it is very difficult to evaluate how “good” the package will be.
- Updating dependencies on a non-trivial project is usually fraught with a domino effect of breakages and/or dependency updates that are time consuming to resolve and test.
On my first point, evaluating a package’s “goodness” – it usually involves a finger in the air “how many people download this?”, “how recently was the code updated?” and “how many GitHub issues are there?” calculation. Since there’s no real JS standard library, we have to do this a lot. Pretty much every added dependency in fact, for an enterprise quality project.
On the second point, yes we have shrinkwrap and yes we can peg our package.json versions to whatever we please — but there still comes a time when you need to update those dependencies and you know all hell will break loose.
Node, NPM and JS in general have reached a level of maturity and popularity that I think these problems shouldn’t still exist today. Perhaps these problems are preventing Node’s adoption by some enterprises.
So here’s my question – do we need a publicly accessible stable, versioned NPM?
Think how Fedora Linux is to Red Hat Enterprise Linux. Fedora takes the latest versions of its dependencies, RHEL is locked down in long-term support releases with older, but stable packages.
For a given RHEL major version, you’ll only get security updates and bug fixes.
Maybe the JS world needs something akin to RHEL.
The real world
When you are tasked with rewriting a major news website from scratch (which I’ve done), the number one thing your stakeholders want (usually implicitly) is for the site to actually work and never break. Your stakeholders don’t (hopefully), and shouldn’t care how the site works — which packages you chose. They don’t care that you’ve used “new-awesome view binding framework 2016” to make the words appear on the page.
When it comes to updating the dependencies on your news website with millions of readers — wouldn’t it be nice if it just worked and you didn’t spend a week resolving the ensuing domino effect?
The existing npm enterprise
Yeah, I know there’s already an npm enterprise, but this is a self-hosted private repository. What I’m proposing would be a public, stable repository where anyone can choose stability over novelty.
How could it work?
For the sake of this discussion, I’m going to call this thing (boringly) “stable-npm”
Just imagine if you could do: (for example)
stable-npm update @latest --saveAnd all your dependencies get updated to the latest version within this stable-npm repository release. No breaking changes, no major new packages with unexpected side effects.
Stable-npm could have a six-monthly or yearly release cycle, where you could do something like:
stable-npm use-repository @v2where you now get packages from the next major version of the repository — and all these packages are guaranteed to co-exist nicely again. Updates would be predictable.
It’d be the closest thing we could get to a JS standard library.
Maybe it could co-exist somehow with the existing npm when you need a package that isn’t part of the stable repository.
The hard bits
From a developer and enterprise point of view this would be amazing. Of course creating this would be non-trivial to say the least.
First, enterprise-grade packages would have to be selected and curated. There’s a maintenance overhead here — the sillier and trivial packages would have to be omitted.
Second, there would have to be some kind of automatic dependency testing. The whole point of the repository is to guarantee working packages. For every patch release that is to be included, its dependencies would also need to be guaranteed to work, as would their dependencies. And so on…
Third, the process of determining which packages end up in the repository would need to be very carefully designed. It would be difficult to objectively cherry-pick packages when everyone has their own use-cases. It would have to be a transparent, documented process to which the majority of users can rely upon.
Final thoughts
Maybe this is already possible, maybe the awesome npm people are already solving these problems or maybe the nature of JS dependencies and packages makes this impossible.
I guess this is a personal wish list after working on a few big projects where dependency management became a major pain point and looking to RHEL’s model seemed to be a good idea.
I already have a day job making software, so I don’t have the resources to think about all of this in enough detail to really iron out the wrinkles — but maybe someone might just read this and say “yes, that’s a good idea- let’s make it happen!”
