back to article NPM not tied in knots over Yarn rival project

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 …

alias yourprogram='npm install && yourprogram'

That wasn't hard now was it...

0
3
Reply
Flame

Doesn't fix the fundamental issue with NPM

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 :)

10
0
Reply

Re: Doesn't fix the fundamental issue with NPM

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.

2
2
Reply
J27

Re: Doesn't fix the fundamental issue with NPM

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.

1
0
Reply
Silver badge

Re: Doesn't fix the fundamental issue with NPM

I recently installed NPM on a new box and by default it now dedupes the subfolders. So that's at least one big problem that's gone away. ;-/

1
1
Reply
Bronze badge
Stop

Re: Doesn't fix the fundamental issue with NPM -- Security

Isn't this the code repo that is most notorious for being tainted by malicious code? Who polices this stuff?

1
1
Reply

Re: Doesn't fix the fundamental issue with NPM -- Security

Yep, and the maintainers refuse to take measures to rectify those types of issues because "it's too hard"...

https://github.com/npm/npm/pull/4016

1
1
Reply
Anonymous Coward

Re: Doesn't fix the fundamental issue with NPM

> 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.

0
0
Reply
Anonymous Coward

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.

3
1
Reply
Facepalm

Optional

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.

2
1
Reply
Silver badge

Re: Optional

Sssssh. You're talking sense. Stop it at once before you scare them and they have to retreat to their "safe zone" or whatever the hell it's called today.

2
1
Reply
Anonymous Coward

Ah, the dinosaurs and the dilettantes!

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. :-)

2
1
Reply

FFS

Would you web developers stop being so damn lazy?

Do you f__king jobs as developers and make a minimal effort to know what code you are including in your application.

Having stuff downloaded dynamically is a blindingly big security hole that the titanic could sail through.

2
1
Reply
Silver badge

Re: FFS

It's not an issue for me, since almost invariably I have to mod my downloaded NPM modules anyway, to accommodate my local needs. By the time I do that, I know exactly what's in the code, oy...

0
1
Reply

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2018