Les distributions Linux sont confrontées au problème des dépendances croissantes des projets, bien que le nombre de dépendances pour le code Python, Perl et Ruby est conservé Dans des limites raisonnables, les projets JavaScript s'exercent à se diviser en très petites bibliothèques, exécutant souvent une fonction simple.
Le référentiel NPM contient déjà plus d'un million de packages et applications typiques lien vers des centaines de dépendances, qui à leur tour ont leurs propres dépendances, ce qui rend difficile la maintenance et la distribution de packages traditionnels avec des applications JavaScript sur les distributions Linux.
En raison de l'imbrication étroite des dépendances des bibliothèques JavaScript, la mise à jour de tout package avec de telles bibliothèques dans une distribution il peut casser d'autres paquets.
Les liaisons de version aggravent le problème: une bibliothèque peut nécessiter une version d'une dépendance pour fonctionner stable, et une autre peut en nécessiter une autre.
De nombreux projets nécessitent les dernières versions des bibliothèques pour fonctionner, qui ne répondent pas toujours aux exigences de stabilité de la distribution (le développement continu est pratiqué dans l'écosystème Node.js en utilisant les dernières versions des frameworks, et la distribution a besoin d'un support pendant plusieurs années).
Tentatives de correction des versions de package dans la distribution uniquement conduire à une augmentation des versions obsolètes dans le référentiel qui n'a pas été mis à jour depuis des années. L'interruption de la maintenance d'un package affecte négativement de nombreux autres packages et crée encore plus de problèmes.
De plus, ldépendances croisées conduisent au fait que de nombreuses bibliothèques de Node.js devient impossible à désinstaller du système, ce qui, à son tour, vous empêche de désinstaller d'autres programmes Node.js.
Pour faire face à cette situation, le projet Fedora a récemment approuvé un plan pour arrêter la formation par défaut de packages séparés avec des bibliothèques utilisées dans les projets basés sur Node.js.
Il a décidé, à partir de Fedora 34, de ne fournir que les packages de base pour Node.js avec un interpréteur, des en-têtes, des bibliothèques primaires, des binaires et des outils de gestion de packages de base (NPM, yarn).
Dans les applications de référentiel Fedora qui utilisent Node.js, Il est permis d'incorporer toutes les dépendances existantes dans un package, sans diviser ni séparer les bibliothèques utilisées dans des packages séparés.
L'intégration des bibliothèques éliminera l'encombrement des petits paquets, simplifiera la maintenance des paquets (auparavant, le responsable passait plus de temps à examiner et à tester des centaines de paquets avec des bibliothèques que dans le paquet principal avec le programme), sauver l'infrastructure des conflits des bibliothèques et résoudre les problèmes de liaison aux versions de bibliothèque (les responsables incluront les versions testées et testées en production dans le package).
L'inconvénient de l'intégration sera la complication du processus de correction aux vulnérabilités dans les bibliothèques, ce qui nécessitera un travail coordonné des responsables de tous les paquets qui incluent la bibliothèque vulnérable. Il y a un risque qu'un paquet oublie de mettre à jour une bibliothèque intégrée vulnérable et le paquet passe inaperçu.
Les développeurs de Debian discute également du changement vers un modèle similaire d'intégration des dépendances dans les paquets. En plus de Node.js, la discussion porte sur la création de packages pour la plateforme Kubernetes et de projets dans les langages PHP et Go, pour lesquels il y a une tendance à se diviser en petites dépendances. Aucune décision n'a encore été prise, mais on espère qu'avec le temps, le problème ne fera que s'aggraver et que tôt ou tard le projet sera contraint de faire quelque chose.
L'interface Web gsa (Greenbone Security Assistant) pour le scanner de sécurité gvm (Greenbone Vulnerability Management) est citée comme un exemple des problèmes rencontrés par les responsables de paquets.
La version de gsa fournie par Debian s'est avérée incompatible avec les versions plus récentes de gvm, mais il n'a pas été possible de mettre à jour gsa vers la version actuelle car elle contient des modifications importantes et utilise npm pour télécharger les bibliothèques Node.js nécessaires.
Les bibliothèques demandées sont trop nombreuses et nécessitent la création de nouveaux paquets dans Debian pour que quelqu'un les maintienne, car les règles Debian interdisent de charger des composants externes pendant le processus de construction.
source: https://lwn.net/
Cette fragmentation des frameworks et des bibliothèques dans ECMAscript est devenue incontrôlable.
Bon article.