Cli: [QUESTION] Existe-t-il un moyen de définir le délai d'expiration pour `npm install`

Créé le 14 avr. 2020 · 11Commentaires · Source: npm/cli

Quoi / Pourquoi

Pour l'instant, nous avons un problème avec le package, quel fichier de méta-info (où toutes les versions sont répertoriées) pèse plus de 110 Mo et il faut 2,5 minutes pour télécharger le fichier sur ma machine, pour notre équipe, l'installation de npm a échoué en raison de

Response timeout while trying to fetch http://regsitry.url/example-meta-file (over 30000ms)

Où

Pour l'instant, sur l'environnement local, j'ai dû régler les fichiers npm, pour changer le délai d'expiration par défaut.
Dans le journal de débogage NPM, j'ai trouvé que le message Response timeout... provenait
~/.nvm/versions/node/v12.16.1/lib/node_modules/npm/node_modules/node-fetch-npm/src/body.js:189:16
Celui-ci sources: https://github.com/npm/node-fetch-npm/blob/latest/src/body.js#L189

J'ai codé cela en dur de cette manière:

    // allow timeout on slow response body
    if (this.timeout) {
      resTimeout = setTimeout(() => {
        abort = true
        reject(new FetchError(`Response timeout while trying to fetch ${this.url} (over ${this.timeout}ms)`, 'body-timeout'))
-      }, this.timeout)
+      }, 5 * 60* 1000) // 5 minutes timeout to prevent failing on huge meta files downloading
    }

Qui

n / a

Références

n / a

La question est donc:

Y a-t-il un paramètre / ENV_VARIABLE, qui peut être passé ou défini avant la commande `npm install` , qui remplacera la `this.timeout` dans le code que je partage.

Bug Needs Discussion Question Release 6.x patch

Source

sidoruk-sv

👍12

Commentaire le plus utile

Le correctif actuel consiste donc à passer à NPM 6.14.5 .

Ce serait parfait lorsque les dernières versions de Node.js (10.x, 12.x, 13.x, 14.x) seront expédiées avec 6.14.5 au lieu de 6.14.4 :
https://nodejs.org/en/download/releases/

sidoruk-sv le 12 mai 2020

👍8

Tous les 11 commentaires

Il convient également de mentionner:
impossible de trouver dans le code @npm/cli ou node-fetch-npm quoi 30000 qui est comme le "délai par défaut" passé à node-fetch-npm manière ou d'

sidoruk-sv le 14 avr. 2020

Semble être utilisé dans make-fetch-happening qui est utilisé dans npm-registry-fetch et pacote. Nous rencontrons un problème où les métadonnées sont devenues suffisamment importantes pour nous pousser plus de 30 secondes dans certains environnements.

Il ne semble toujours pas y avoir de moyen de configurer l'option magique timeout - https://github.com/npm/cli/blob/latest/lib/fetch-package-metadata.js#L56 - L58

darrinholst le 14 avr. 2020

Idem ici je le poste sur ionic cli github
https://github.com/ionic-team/ionic-cli/issues/4387

murtada-dev le 14 avr. 2020

le passage à la version 6.13.x l'a résolu pour moi - https://github.com/npm/cli/commit/ea0ff56cb6ad4bbf208dd3cf39a35e07fc2dff16#diff -3c78131ed196efbd3ce9fdee2df36e24R79

darrinholst le 14 avr. 2020

🚀2

@darcyclarke pour l'instant, nous avons plus de problèmes à cause de cela, car la dernière version de Node.js v12.16.2 a été livrée avec NPM v6.14.x par défaut.

On dirait que la mise à niveau de npm-registry-fetch dans NPM v6.14.0 a causé notre problème avec un timeout comme @darrinholst mentionné précédemment:
https://github.com/npm/cli/commit/ea0ff56cb6ad4bbf208dd3cf39a35e07fc2dff16

Sans la possibilité de redéfinir le délai d'expiration pour ce npm-registry-fetch dans NPM v6.14.x, nous avons dû fixer la version Node.js à 12.16.1 car c'est la dernière version avec NPM v6.13.x.

Et il semble que ce soit un bogue, car avant cela, les changements https://github.com/npm/cli/commit/ea0ff56cb6ad4bbf208dd3cf39a35e07fc2dff16#diff -acf38193ec0e2d9a3b9dc202f239a77aR12, ce n'était pas du tout un énorme problème de méta-fichiers.

sidoruk-sv le 15 avr. 2020

🚀1

@ sidoruk-sv vous remercie d'avoir porté ceci à notre attention. Je vais reprendre cela en interne et voir si nous pouvons expédier un correctif pour résoudre cela et / ou trouver / introduire un drapeau.

darcyclarke le 15 avr. 2020

Nous ne sommes pas en mesure de déployer notre projet, le plus souvent, le méta-fichier Webpack expire, parfois Firebase. Cela a empiré les dernières semaines, il semble que le méta-fichier ait maintenant atteint un point où il échoue constamment. Nous essaierons de revenir à la version 6.13.7.

Edit: après la rétrogradation, nous avons obtenu la première version verte après 10+ échecs, cela semble prometteur.

RiZKiT le 22 avr. 2020

😕1

Voir https://github.com/npm/npm-registry-fetch/issues/26

Remettons le délai d'expiration par défaut à zéro pour nrf v4 (npm v6), augmentons-le jusqu'à 5 m dans la dernière (npm v7) et ajoutons une option --fetch-timeout dans la CLI v7 pour définir cela explicitement.

Je pense que cela résoudrait le problème immédiat et nous mettrait dans une meilleure position à l'avenir.

isaacs le 23 avr. 2020

👍6

Le correctif actuel consiste donc à passer à NPM 6.14.5 .

Ce serait parfait lorsque les dernières versions de Node.js (10.x, 12.x, 13.x, 14.x) seront expédiées avec 6.14.5 au lieu de 6.14.4 :
https://nodejs.org/en/download/releases/

sidoruk-sv le 12 mai 2020

👍8

la documentation npm config a plusieurs entrées pour les délais d'expiration. Ce code ignore-t-il ces paramètres ou n'y a-t-il aucun paramètre pour ce cas spécifique et c'est le problème?