Un autre paquetage npm qui tient sur une ligne de code responsable de dysfonctionnements au sein d’un gros pan de l’écosystème JSUne redite qui concerne des millions de dépôts
Comment en tant que développeur web procédez-vous pour savoir que vous avez affaire à un objet Promise ? Dans l’univers JavaScript, à défaut d’effectuer une recherche sur Google pour voir comment des pairs abordent le problème, l’approche la plus directe est d’installer un paquetage pour l’environnement d’exécution Node.js. À date, c’est ce qu’ont fait plus de 3,4 millions de responsables de dépôts GitHub avec le paquetage is-promise. Ce dernier dont le rôle se résume essentiellement à renvoyer un booléen à l’issue du test tient sur une ligne de code :
| Code : | Sélectionner tout |
return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function';
Jusqu’à il y a peu, le paquetage ne fonctionnait pas avec la version 13 de Node.js en bêta. En substance, une erreur d’importation de ce dernier (dans sa version 2.2.0) que certains des nombreux utilisateurs n’ont pas manqué de remonter à l’équipe du projet Node.js. Illustration avec un des écrans d’erreur mis à disposition par un contributeur :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | sorunome@sorunome-desktop repos/mx-puppet-skype $ node ./build/index.js 1
internal/modules/cjs/loader.js:616
if (e.code !== 'ERR_PACKAGE_PATH_NOT_EXPORTED') throw e;
^
Error [ERR_INVALID_PACKAGE_TARGET]: Invalid "exports" main target "index.js" defined in the package config /home/sorunome/repos/mx-puppet-skype/node_modules/is-promise/package.json
at resolveExportsTarget (internal/modules/cjs/loader.js:574:13)
at resolveExportsTarget (internal/modules/cjs/loader.js:613:20)
at applyExports (internal/modules/cjs/loader.js:503:14)
at resolveExports (internal/modules/cjs/loader.js:541:12)
at Function.Module._findPath (internal/modules/cjs/loader.js:661:22)
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:963:27)
at Function.Module._load (internal/modules/cjs/loader.js:859:27)
at Module.require (internal/modules/cjs/loader.js:1036:19)
at require (internal/modules/cjs/helpers.js:72:18)
at Object.<anonymous> (/home/sorunome/repos/mx-puppet-skype/node_modules/lowdb/lib/main.js:4:17) {
code: 'ERR_INVALID_PACKAGE_TARGET'
} |
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | module.exports = leftpad;
function leftpad (str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch !== 0) ch = ' ';
len = len - str.length;
while (++i < len) {
str = ch + str;
}
return str;
} |
Si le cas du paquetage is-promise n’a pas manqué de susciter des questionnements quant à la nécessité de s’appuyer sur tout un module pour une ligne de code, il interpelle surtout sur ce qui est de la bibliothèque standard de JavaScript. Dans le cas d’espèce, l’un des problèmes est que les porteurs des projets informatiques susceptibles de prendre un coup parce que s’appuyant sur le paquetage is-promise auraient pu choisir de faire usage de la gestion des Promises disponibles sous JavaScript (via la bibliothèque standard du langage). Toutefois, même en prenant en compte cet élément, des développeurs estiment que l’une des plus grosses tares du langage JavaScript est le fait pour sa bibliothèque standard de ne pas être ouverte sur suffisamment de cas de figures, ce qui pousse des développeurs tiers à proposer des modules (avec ce que l’on relève comme inconvénients).
Si l’on ne peut s’avancer à dire qu’il s’agit du seul souci au sein de l’écosystème JS, il faut dire qu’il y a comme une reconnaissance au plus haut niveau de ce que la bibliothèque standard est problématique. En effet, le créateur de Node.js est lancé sur l’effort Deno. C’est un nouvel environnement d’exécution doté d’une bibliothèque standard qui est un portage de celle du langage Go de Google. Le projet est au stade de l’enfance, en route vers sa version 1.0, donc pas à utiliser en production. Ryan Dahl a glissé un mot à son propos lors de la JSConf qui s’est tenue en Europe en 2018.
Source : GitHub
Et vous ?
Qui est le plus à blâmer dans ces situations de dysfonctionnement ? Celui qui met au point le paquetage ou ceux qui l’adoptent en masse ? Quels sont les aspects de la gestion des paquetages qui vous chiffonnent le plus en JavaScript ? Que pensez-vous de l’initiative deno ? Pensez-vous qu’elle apporte une réponse efficace aux problèmes de l’écosystème JavaScript ? Voir aussi :
npm 6.0.0, le gestionnaire de paquets officiel de Node.js. passe en @latest, et se concentre désormais sur la sécurité npm 5.7.0 retiré de la circulation à peine deux jours après sa sortie, la version 5.7.1 publiée pour corriger un problème critique npm en version 5.7.0 est maintenant disponible, l'alignement vers les pratiques DevOps se poursuit
Vous avez lu gratuitement 3 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Envoyé par Sodium
