IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un autre paquetage npm qui tient sur une ligne de code responsable de dysfonctionnements au sein d'un gros pan de l'écosystème JS
Une redite qui concerne des millions de dépôts

Le , par Patrick Ruiz

335PARTAGES

7  0 
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'
}
Si le problème est désormais résolu, il faut dire qu’il est caractéristique de l’écosystème JavaScript. En effet, il n’est pas sans faire penser à celui du paquetage left pad – un ensemble construit non pas sur une, mais 7 lignes de code.

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;
}
En 2016, le développeur Azer Koçulu a supprimé plus de 250 de ses modules du gestionnaire de paquets npm. Avec le retrait de ces derniers, ce sont des milliers de projets dont Node et Babel qui avaient ainsi été mis à mal. À l’époque, Laurie Voss avait opté pour la mesure sans précédent de restaurer une version de la bibliothèque nécessaire au fonctionnement de plusieurs sites et applications web.

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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de nouknouk
Modérateur https://www.developpez.com
Le 29/04/2020 à 19:39
Citation Envoyé par Sodium Voir le message
Ben comme d'hab #JavaScript quoi.
Comme d'hab, Sodium, quoi.
11  1 
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 29/04/2020 à 23:04
Si je lis bien la news, il y a eu un problème rapidement résolu dans le système de packages de loin le plus utilisé au monde.
Le précédent problème du même genre datant d'il y a quatre ans.
Donc ça fonctionne plutôt bien en fait.
10  0 
Avatar de xhe11662
Membre du Club https://www.developpez.com
Le 29/04/2020 à 19:34
Comment en tant que développeur web procédez-vous pour savoir que vous avez affaire à un objet Promise ?
Code : Sélectionner tout
fetch('/') instanceof Promise
6  0 
Avatar de Dave Hiock
Membre confirmé https://www.developpez.com
Le 30/04/2020 à 9:45
Tout développeur se doit de tester, dans son contexte voir plus, avant utilisation et ne pas faire une confiance aveugle à du code fournie par un tiers et c'est donc ce qui c'est fait puisque le problème a été remonté rapidement.

Citation Envoyé par Sodium
La vidéo avait l'air intéressante sinon mais un type qui lit un PowerPoint en bégayant pendant 25 minutes c'est juste pas possible.
Ce que je trouve « juste pas possible » c'est qu'en 2000 ans l'homme a quand même évolué, je vous laisse jugé en bien ou en mal, alors que sodium en 2000 messages continue de nous asséner toujours et encore sa même litanie, cela en devient pathétique !
6  1 
Avatar de Phago
Membre habitué https://www.developpez.com
Le 30/04/2020 à 11:27
La vidéo avait l'air intéressante sinon mais un type qui lit un PowerPoint en bégayant pendant 25 minutes c'est juste pas possible.
Ok on en reparle quand tu feras 300k views sur un talk, inventé un framework web et que tu auras révolutionné des concepts en informatique ?
5  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 30/04/2020 à 11:40
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 ?
On ne peut pas reprocher au contributeur de proposer quelques chose, même si on peut discuter de l'utiliter de la chose.
Par contre quand le premier reflexe c'est de faire un npm install + require pour un truc qui tiens en une ligne ... Faut se remettre en question.
Le problème c'est que le cout d'ajout d'une dépendance est quasi nulle , donc pas mal de dév les empile sans se poser la moindre question.
En C++ , par exemple, sans conan ou vcpkg , tu te pose la question 2x avant d'ajouter une dépendance externe. J'ai un projet où , si je veux ajouter une dépendance static, c'est à minima 4 compilations différentes pour 3 architectures, 3 os ... Autant dire qu'il faut que ca vaille le coup et que un "is-promise" finirait simplement dans un helper.

Quels sont les aspects de la gestion des paquetages qui vous chiffonnent le plus en JavaScript ?
Pour moi c'est le "dependecy hell". La moindre dépendance se traduit souvent par l'ajout implicite de 10 aines d'autres sans qu'on est aucun contrôle dessus. On peut ainsi très rapidement récupérer un code dangereux sans même s'en apercevoir (npm alerte la dessus mais bon ...).
5  0 
Avatar de Doksuri
Expert confirmé https://www.developpez.com
Le 30/04/2020 à 8:33
a quel moment, en tant que dev... t'as besoin de tester si c'est une promesse ???
je ne comprends pas a quel moment ca peut t'etre utile...tu vas ecrire du code en random en esperant que ca passe ?

je veux dire... t'utilise une methode... tu te renseigne dessus... au pire, tu console.log la methode et tu vois bien que c'est une promesse... et tu continues ton code sachant ca...

t'achetes pas une voiture, et arrive a la pompe a essence tu te dis... "heu... aller, on va dire que c'est du 98 qu'il lui faut" en esperant que ca passe
6  2 
Avatar de Doksuri
Expert confirmé https://www.developpez.com
Le 30/04/2020 à 9:54
Citation Envoyé par frfancha Voir le message
Les API dans les packages JavaScript fonctionne souvent avec un paramètre "souple".
Dans lequel tu peux passer une chaîne de caractères, un tableau, un objet, une fonction, une promesse,...
Le comportement de l'API étant de plus en plus complexe en fonction de l'objet passé.
La chaîne de caractères (ou un simple nombre) va utiliser tous les paramètres par défaut, l'objet va permettre d'en customiser certains, la fonction va permettre une initialisation "lazy", la promesse passe en mode asynchrone,...
Donc oui tester si c'est une promesse ou pas se fait très souvent.
C'est comme l'overloading du type du paramètre en Java ou C#, sauf que là il existe une API par type et la bonne est choisie à la compilation.
=> ok, je vois mieux ou ca pourrait pecher...

je pense qu'un moment il faut aussi peser le pour & le contre entre souplesse & maintenabilite
4  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 30/04/2020 à 8:55
voila pourquoi j'aime typescript...
et swagger avec des services correctement typés
3  0 
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 30/04/2020 à 15:42
Citation Envoyé par SimonDecoline Voir le message
Perso, quand un problème qui s'est déjà produit se produit à nouveau, je n'appelle pas ça "fonctionner plutôt bien".
Ce n'est pas du tout le même problème qu'il y a 4 ans.

Il y a 4 ans c'était le mainteneur d'une dépendance utilisée dans un très grand nombre de dépendances qui avait été supprimée du registre.

Ici c'est une dépendance existante qui n'est pas compatible avec une version beta de la plateforme. Le problème n'existe donc que si tu utilises le package (non patché) avec la dernière version beta de node.
3  0