Dependency Injection in Node.js

The Linux kernel, for a time, and now NodeJS, Gnome, among others, use/used odd MINOR version numbers to denote development releases. Its a cool practice that tells the developer at a glance how much hardening a release has had. Linux has since dropped this practice and has moved to a more rapid release schedule.

Earlier I wrote the version number is “mostly arbitrary”, and you hated me a little bit for it. It is true, we all know it, we assign logic to a magic number. Some projects practice the relatively recent Semantic Versioning spec which seeks to resolve so called ‘dependency hell’. It codifies the long standing de facto version schema of X.Y.Z where X is MAJOR changes, Y represents MINOR updates and Z is a PATCH to the minor update stream.

Dependency hell boils down to global dependency conflict resolution. If package A depends on version 1 of package B and C, but C depends on version 2 of package B: ur head asplode.

NodeJS solved this one in a startlingly simple and, in hindsight, what should’ve been obvious way. They simply removed the idea of a global package. With only a local scope a package contains its own dependencies, often frozen (or vendored) into the package itself. Brilliant: lexical scope for the package artifacts themselves. No dependency hell. No false hope that the maintainers faithfully adhere to the plausible rigor of Semantic Versioning.