alias yourprogram='npm install && yourprogram'
That wasn't hard now was it...
NPM, keeper of the npm Registry and the software package management tool called npm that pulls JavaScript packages from said registry, is testing another sort of package manager called tink. Previously referred to as frog and then crux, until someone discovered there was an npm package called crux, tink represents an attempt …
Having done a few years of professional JavaScript development (*twitch*), including NodeJS (*double twitch*), I have come to realise that most people acknowledge and yet accept NPM's overwhelming design failure.
I still fear the npm_modules folder to this day because it would often grow to such enormous sizes (500+ MB sizes were seen in many projects) that one would risk crashing or hanging whatever file browser one was using to take a peek at one of the hundreds of dependencies that get drawn in.
Yet that's not the problem. The problem is that NPM is dumb. Like, really, really dumb. Instead of actually being a dependency manager, it's merely a downloader for JS files. That's it. This results in each node_modules folder being full of sub-sub-sub-sub folders containing the same 120 kB JS snippet 'library' that is present in 90 other folders, of which many sub-dependencies will also draw in that same snippet so that it feels like 90% of the node_modules folder is just duplicated content.
Oh, and having to install many dependencies both globally and local (like 'Gulp'), or else stuff cannot be found. More duplication. More cruft.
After a few years of that Hellscape I'm now happily back with C, C++ and similar projects where I get to use Apt, Pacman and kin to manage dependencies. I feel that one day soon I may perhaps feel like I can smile again.
Just my $0.02 :)
NPM has been deduplicating dependencies in node_modules since v3 (2015). The tool is not perfect, the lock mechanic is still occasionally flaky when people use different NPM versions to update their deps, but all things considered it's a very good dependency manager with a huge community. What I don't like as much is the commercial nature of the NPM repo. It's been OK so far but the future is uncertain.
And I don't share the enthusiasm for the C/C++ model. When working in a very small team, OK, fine. But how do you keep deps synced across large/distributed teams? I'd rather focus on building new stuff rather than spend my energy on something that can be easily automated.
NPM deduplication is terrible, it should be managing all packages at the top level, without subs. It definitively doesn't do that. The NPM repos aren't always that reliable either which can make depending on them a very expensive problem sometimes.
> I still fear the npm_modules folder to this day because it would often grow to such enormous sizes
> Yet that's not the problem. The problem is that NPM is dumb. Like, really, really dumb. Instead of actually being a dependency manager, it's merely a downloader for JS files
Well, I do not know about the project talked about here since it is at such an immature stage, but those two points of yours are precisely what the "competing" Facebook project addresses, as seen from the PDF linked in the article.
The biggest problem with npm packages is that there's no concept of a runtime, SDK, or source package. Developers publish whatever they feel like, and there's tons of bloat in any given that you don't actually need. Even the content of the package.json file contains garbage only needed during the development of the library.
So, the solution to the problem concerning node.js of managing the vast amounts of package dependencies, resulting code is being loaded from all over the internet, therefore meaning you don't know what code is running on your production system at any given time, is to make the process of loading this code invisible to the developers of said production system. Either I'm not properly understanding the problem or this solution sucks.
Just as I expected. :-)
Now one poster, Maya, gives an accurate description of npm and yarn (not Node, since dependency management is not intrinsic to Node).
She appears to be describing the state of package management as of three or four years ago which, as already pointed out has seen some improvement although the downloads *are* still huge for a project of any size. Also, global installs are a matter of preference, as is the user cache, and the number of dependencies is often inversely proportional to the speed and carefulness of development: better crafted packages tend to have less dependencies and smaller dependency trees. Do note however that this doesn't say anything about code quality, if you know what quality actually is.
Where I disagree with her is in her conclusions: Node + npm / yarn is not good or bad, better or worse because of those dependency trees. That is quite simply the way it is designed, which will be advantageous in some projects / project stages and not in others. E.g., if you are looking for prototyping speed and efficient runtime performance Node is often a good choice.
It is also, in my experience, quite orthogonal to C / C++ so I do not understand the comparison. The two can and often do coexist in the same project but I can't see them being competing alternatives for the same role. One typical example, again from my experience, is to prototype (not merely mock up) with liberal use of existing dependencies so that one can get to testing extremely quickly, and then improve performance (or other parameters) by rewriting critical parts of the system as C or C++ Node modules. What this gives is a smooth transition from prototype to production and an incredible boost in development speed. I have implemented the same project at different times as pure C++, C++ + PHP API, and C++ + Node so I can compare (albeit only one data point). In the original C++ project (which was in turn a reimplementation of earlier C + Lisp code) it took about ten days, if memory serves, to get a minimally testable build running. The Node version was less than a day, which allowed us to invest the rest of the time in testing, fine tuning the requirements, and eventually delegate the speed critical bits to a C module. That project, last time I checked, serves about a million unique visitors per day and has matured and evolved at an impressive rate since I was last involved.
Should we have a show of hands? How many in the audience here have actually used Node in medium to large scale production projects (as opposed to hobbyist tinkering)?
(puts hand up, 1,200+ hours of actual Node production coding on the back of 20-odd years of C, C++, Lisp and Forth experience)
Those who put hands up, it would be interesting to hear your thoughts. :-)