How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript

What a cluster-mess.

I like node. I’d like to do more work with node. But this type of things is what gives me nightmares when working with NPM packages. Seemingly endless lists of dependencies and sub-dependencies, and if someone screws one of them up, the whole house of cards can collapse.

And that’s aside from the current hierarchical dependency module, which on Windows can cause issues with moving/removing project, due to overly long paths. Granted, that’s a Windows file system issue, but it shows up because of a lack of forethought in the design of the NPM dependency model.

Will be interesting to see what the fallout of this is.

Common misconception. Windows supports path lengths up to ~32,768 characters: Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn

Now, the shell, common dialogs, miscellaneous tools, etc (whether Microsoft or other, built-in or not) might not (probably don’t), but it’s not a filesystem (or Windows) issue.

@ godefroi - Fair point. Sloppy terminology on my part, but the end result for the user remains that you can easily end up in a situation where things that should work (moving and/or deleting folders) don’t.

Wow… I was feeling bad for the coder (Azer) after reading his blog post, but after reading the entire thread of emails between Kik, NPM, and Azer on Kik’s reply… I have to say that Azer was a complete prick about the whole thing, acting like a 12 year old “anonymous” dork.

I don’t feel sorry for him at all.

1 Like

Oh for the old days of Delphi.

and COBOL!

@ suitable1 - I was a Fortran kind of guy that fast back, oh ya I remember punch cards.

A colleague on one of my Slack channels pointed out that one way to mitigate issues like this is to create a private NPM registry within an organization, which I suppose is a good option if your application/organization is large enough to merit the overhead of creating it and keeping it maintained/updated.

It’s an interesting problem to consider. I suspect (though I don’t claim to be sufficiently expert to know with certainty) that dependencies are a bigger issue with NPM than, for example, nuget, due to NPM modules often (in my experience) having more, but smaller-grained, dependencies than your typical nuget package.

On the plus side for NPM, that speaks to a more collaborative community than what exists for nuget, but the downside is that there are more touchpoints where a boneheaded (or malicious) move on the part of a module author can cause mayhem, even if only for a short time.

How one prevents or copes with these issues is definitely something that remains imperfectly solved at best.