NPM hell, it's more than a package dependency problem
Welcome,
Let me get you deep into one of the most controversial problems of every developer using npm or any JavaScript library. In this article, we will investigate, analyze, test, and learn about this issue inside of it, but let's discuss it first of all. So many articles try to explain this topic, but most copy each other or contain no more than three paragraphs. I am glad to present this piece of summaries about npm and its problems. You may find references and source code at the end of this document.
When and why npm hell may happen
Here is the set of facts I found using npm. We should understand - NPM hell is not just a single problem; it is an unbelievably massive group of different issues: from incorrect ^ symbols used in versioning your project dependencies to packages that need visual studio tools (those are the most hateful for every developer! ), they all have a common flaw - versioning and system problems.
For me, windows npm problems it's a different world of bugs and a different cluster of hells because if you are a Windows user, be ready for python2/3 conflicts usage in npm installers (these conflicts will be fixed only once you reinstall the whole stack - node, npm e.t.c.), prepare your system for using different command-line applications, because some of them may use CMD, while other PowerShell and so and so, from stuck installer in the terminal with no progress information, which I drop so many times with no ideas about the installation processes under this blank screen to WSL access rights conflicts. All these problems show each developer that the npm must be strictly controlled with attention!
How to recognize that you are in the fire
The typical development using Node.js starts from these commands known to everybody:
- npm install
- npm audit fix (--force)
(note: most changes applied for the package-lock.json)
Let's imagine that some of your packages are outdated, and you start detecting packets by running `npm outdated` and then `npm update ` to fix that quickly. Here You see the extensive list of warnings: this is the first step into an npm dependency hell [4]
This problem may be fixed by running `npm audit fix` a second time, but what would you do if the package.json will have conflicts with the package-lock.json for some reason? Or will your node_modules contain too many different versions of one library? (here, the size of the project might be more than 700MB) or what will you do if the node-gyp dependencies will block out the installation of each project in your system?!:
Keep an eye on npm strictly.
Here is some advice to keep your npm versioning outside of the hell from my experience as a Windows user:
- Automate your releases and semantic versioning with semantic-release
- NPM is hands-down the most popular packaging ecosystem online. So, of course, we need to patch packages with risky vulnerabilities immediately; otherwise, with each second
- problem grows in geometry progression.
- Learn more about migration rules of packages you use
- Learn more about versioning symbols and use them with attention [6]
- Avoid using expired packages. Maintain them as regularly as possible (this was the actual case when we were looking for a problem, while some of our boxes were just expired)
- Do not run npm install --save while testing some libraries
- Do not forget to update your lock file when it's needed by running npm install --save
- If you are a Windows user, be ready for a long trip through visual studio tools and Python conflicts. Check your PATH variable and software versions with attention
DO NOT USE WSL AS ADMINISTRATOR installing the node.js npm stack on your machine AT ALL, even if it's asking you for root rights (this problem will reduce massive access rights conflict in your system)
Summary
Thanks for reading this article; remember to keep your dependencies tide.
It is difficult to describe many problems in a single article, so remember to check references for more information! Please fill free to mail me feedback about this article: nikborsh.ufo@gmail.com
Ref
[1] https://medium.com/@osman.sist/npm-hell-97f0459964cc
[2] https://npm.github.io/how-npm-works-docs/theory-and-design/dependency-hell.html
[3] https://docs.npmjs.com/cli/v8/commands/npm-audit
[4] http://russelljanderson.com/dependency-hell/
[5]https://hackernoon.com/these-6-essential-tools-will-maintain-your-npm-modules-for-you-4cbbee88e0cb
[6] https://dev.to/mikel_brierly/deliver-us-from-dependency-hell-g36
[7] http://npm.anvaka.com/#/view/2d/netbeast-cli - visualize dependences
[8] https://github.com/chrisbateman/webpack-visualizer