If you're a JavaScript developer at any level, then you have probably used the popular package manager NPM at some point in time.
NPM makes installing, updating and managing library dependencies super easy with just a few basic commands that pretty much any developer can remember.
I personally use it all the time for my full-stack JavaScript applications professionally and non-professionally. And, aside from bloating my project file sizes from time to time, I haven't faced any serious issues. At least not yet.
But that's not to say that you won't face any issues. Because NPM isn't foolproof and there are some potential issues that can spring up that can make for a bad development day.
Corrupted modules
Just recently two very popular NPM libraries came under scrutiny after it's developer seemingly corrupted the source code essentially breaking many builds around the world.
Faker.js and Colors.js are two heavily used utility libraries that help developers with writing their code. Faker.js can generate random data for testing purposes and colors.js allows for style editing on a developers console window.
These aren't production modules, in the sense that they are for development use only and should not be included in any production builds. But again, millions of developers rely on them on a daily basis to get their work done.
Faker.js gets around 2.8 million downloads per week while colors.js sits at around 25.8 million weekly downloads. I don't personally use either of these myself.
Needless to say, alot of developers were mad when they woke up that morning to sporadic error messages. While builds failed around the world and programmers brewed their second pots of coffee, GitHub moved quickly and released a security advisory informing developers that they should downgrade to the previous functional version.
There is a good chance that this didn't really cause any major issues to developers. Maybe just a slight morning annoyance if anything. But, it definitely points out the fact that shifting over coding responsibility to an unknown open-source codebase isn't the idea scenario sometimes.
Needless to say, this happens all the time but typically not for any malicious reason. Developers make mistakes and they deploy broken code to production all the time. If 2 or 3 people are using that library, then it isn't really a big deal. But if millions of developers are relying on this code that often times is only managed by 1 or 2 people, then there is a problem.
Angry developers
Sometimes developers go beyond corrupting a module and simply just remove the code altogether from the internet. Fair enough and it is their right to do so.
As was the case in 2016, when then 28-year old developer Azer Koçulu became the center of controversy when he removed his entire coding library from NPM.
Azer was in the process of releasing his latest open-sourced library titled Kik when he was approached by a patent lawyer seeking that he turn over rights to the name. As it turns out, there was a popular chat application by that very same name.
Azer refused to hand over the rights to the name and continued on with his work. NPM eventually sided with the lawyer claiming that users would confuse Azer's new library with the application.
A short time after Azer made the choice to remove all of his libraries from NPM. One of those libraries however was a very popular dependency used by millions of developers and by very large organizations.
Once again, developers woke up that morning to broken builds. In order to remediate the issue, NPM made the unprecedented choice of re-uploading the library in question against its owners will. Potentially, this could have created some form of friction between the open-source community and npm. Though many developers (with broken builds) would probably argue that this was the right choice.
But it's tough to really put blame on anyone here. Azer, as the owner of the code, had all of the right to remove his work from the internet.
And NPM, thinking of its clientbase and shareholders, made the tough decision to reupload the library to prevent any further issues.
Most open-source developers make little to no money on their projects. And often times, these small modules end up getting used by millions of people worldwide, including mega corporations. Add patent lawsuits to the equation, and no developer would be blamed for deciding to step away.
Versioning
This is both a great feature and a troublesome feature when it comes to relying on NPM dependencies.
Well maintained code will usually go through various phases of revisions as developers add and features and improve performance.
Sometimes however that revision includes completely removing methods altogether from the library. Meaning that any developers looking to update their codebases would essentially be out of luck, as they risk breaking their current builds.
This happened to me recently when updating my code to use React Router v.6 from v5. I should have read the release notes truth be told. Version 6+ is not at all version 5. Functions were removed, others were renamed and new ones were added.
This meant, once again, broken builds. The benefit of NPM is that you can easily revert back to an older version whenever you wish. But that also means that you might find yourself with outdated libraries in a dependency soup at some point in the future.
Note that this isn't solely an NPM issue. If you were managing modules and libraries yourself manually, you would still end up very much with the same issues.
But because NPM makes updating and installing such a simple task, you might find that conflicts occur more frequently.
Lastly
If you're using NPM, don't stop using NPM. It's a great tool for developers at any stage and it showcases tens of thousands of human developer hours.
Most of the websites that you frequent on a daily basis probably would not function well without some library in NPM.
But it's important to spend some time learning about any particular library and seeing just how it is being developer before diving in and mixing it into your codebase.