www.thatsoftwaredude.com
The biggest risks with using NPM
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. … 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. … 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. … 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. … 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.LastlyIf you're using NPM, don't stop using NPM.
Related Pain Points2件
Corrupted or malicious npm package code breaking builds worldwide
9Popular npm libraries like Faker.js and Colors.js have had their source code corrupted by maintainers, causing widespread build failures across millions of dependent projects. When heavily-used small modules maintained by 1-2 people break, the impact cascades globally.
NPM Caret Versioning Creates Unpredictable Dependency Updates
7NPM's default use of caret (^) versioning allows automatic minor and patch version updates that can introduce unexpected breaking changes, hidden regressions, and version incompatibilities. This undermines reproducible builds and creates silent failures in CI pipelines.