Version bindings exacerbate the problem: one library may require one version of a dependency to run stable, and another may require another.
Many projects require the latest versions of the libraries to work, that do not always meet the stability requirements of the distribution (continuous development is practiced in the Node.js ecosystem using the latest versions of frameworks, and the distribution needs support for several years).
Attempts to fix package versions in the distribution alone lead to an increase in outdated versions in the repository that haven't been updated for years. Disruption of maintenance for one package adversely affects many other packages and creates even more problems.
In addition, lcross dependencies lead to the fact that many libraries of Node.js become impossible to uninstall from the system, which, in turn, prevents you from uninstalling other Node.js programs.
To deal with this situation, the Fedora project recently approved a plan to stop the default formation of separate packages with libraries used in Node.js-based projects.
He decided, starting with Fedora 34, to supply only base packages for Node.js with an interpreter, headers, primary libraries, binaries, and basic package management tools (NPM, yarn).
In Fedora repository applications that use Node.js, it is allowed to embed all existing dependencies in a package, without dividing and separating the libraries used in separate packages.
Embedding libraries will get rid of small package clutter, simplify package maintenance (previously the maintainer spent more time reviewing and testing hundreds of packages with libraries than in the main package with the program), save infrastructure from conflicts of libraries and resolve issues with linking to library versions (maintainers will include tested and production-tested versions in the package).
The downside of integration will be the complication of the process of bringing corrections vulnerabilities in the libraries, which will require a coordinated work of the maintainers of all the packages that include the vulnerable library. There is a danger that a package will forget to update a vulnerable built-in library and the package will go unnoticed.
The developers of Debian are also discussing switching to a similar package dependency integration model. In addition to Node.js, the discussion touches on the creation of packages for the Kubernetes platform and projects in the PHP and Go languages, for which there is a tendency to divide into small dependencies. No decision has yet been made, but it is hoped that over time the problem will only get worse and sooner or later the project will be forced to do something.
The gsa (Greenbone Security Assistant) web interface for the gvm (Greenbone Vulnerability Management) security scanner is cited as an example of the problems that package maintainers have.
The Debian-shipped version of gsa turned out to be incompatible with newer versions of gvm, but it was not possible to update gsa to the current version as it contains significant changes and uses npm to download the required Node.js libraries.
The requested libraries are too many and require the creation of new packages in Debian for someone to maintain them, as Debian rules forbid loading external components during the build process.