NPM hell, it's more than a package dependency problem

Let me get you deep into one of the most controversial problems of every developer who ever used npm or even any JavaScript library. In this article, we will investigate, analyze, test, and learn about this issue inside of it, but let's discuss first of all. So many articles are trying to explain this topic, but most of them just copy each other or contain no more than 3 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 the single problem, it is an unbelievably huge group of the different problems: from incorrect ^ symbols used in versioning your project dependencies, to packages that need visual studio tools (those ones are the most hateful for every developer! ) , they all have a common flaw - versioning and system problems.
For me, windows npm problems it's the different world of bugs and a different cluster of hells because if you are windows user, be ready for python2/3 conflicts usage in npm installers (this 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 common development using Node.js starts from these commands known for 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 packages by running `npm outdated`, than `npm update ` to fix that quickly and here You see the big 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 your node_modules will contain too many different versions of one library? (here the size of the project might be more than 700MB) or what are you gonna do if the node-gyp dependencies will block out the installation of each project in your system?!:

Keep eye on npm strictly

Here is some advice to keep your npm versioning outside of the hell from my experience as 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 is the real case when we were looking for a problem, while some of our packages 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 its asking you for root rights (this problem will reduce huge access rights conflict in your system)


Thanks for reading this article, don't forget to keep your dependencies tide.
It is difficult to describe a whole bunch of problems in a single article, so do not forget to check references to see more information! Fill free to mail me feedback about this article:

[7] - visualize dependences