Linux distributions are facing a problem with project dependencies growing. While the number of dependencies for Python, Perl, and Ruby code is kept within reasonable limits, JavaScript projects practice splitting into very small libraries, often performing one simple function. The NPM repository already has over a million packages, and typical applications link with hundreds of dependencies, which in turn have their own dependencies, making it difficult to maintain and distribute traditional packages with JavaScript applications in Linux distributions.
Due to the tight intertwining of JavaScript library dependencies, updating any package with similar libraries in a distribution can break other packages. The problem is aggravated by version bindings – one library may require one version of the dependencies for stable operation, and another – another. Many projects require the latest versions of the libraries to work, which do not always meet the stability requirements of the distribution. Attempts to stabilize package versions only lead to an increase in outdated versions in the repository that have not been updated for years. Discontinuing maintenance of a package negatively affects many other packages and leads to even more problems. In addition, cross-dependencies make it impossible to uninstall many Node.js libraries from the system, which, in turn, prevents you from uninstalling other Node.js programs.
In order to deal with this situation, the Fedora project approved a plan for discontinue separate bundles for libraries used in Node.js projects. 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 the Fedora repository applications using Node.js, it is allowed to embed all existing dependencies into one package, without splitting and separating the libraries used into separate packages. Embedding libraries will allow you to get rid of the clutter of small packages, simplify package maintenance (previously, the maintainer spent more time reviewing and testing hundreds of packages with libraries than on the main package with the program), save the infrastructure from library conflicts and solve problems with linking to library versions (maintainers will include production-tested and tested versions in the package). The downside of this integration is the difficulty of communicating vulnerabilities in libraries, which will require coordinated work by the maintainers of all packages that include the vulnerable library.