Échecs du proxy npm lors du téléchargement des scripts d'installation

Si une installation npm passe le téléchargement depuis le registre et s'arrête dans un script d'installation, identifiez le second téléchargeur. Le paquet JavaScript peut déjà être présent alors que son binaire spécifique à la plateforme manque encore.

1. Retrouvez le responsable de la requête dans le journal. Notez le script de cycle de vie, l'exécutable ou la bibliothèque HTTP, le nom d'hôte de destination et la première erreur. Un paquet peut lancer un autre programme dont le téléchargement est distinct du transfert du registre npm.
2. Utilisez l'interface proxy prise en charge par ce téléchargeur. Pour le chemin resources.js de tfjs-node, l'environnement proxy du processus enfant en est un exemple concret. Vérifiez les paramètres de téléchargement documentés du paquet et l'environnement du processus qui émet la requête. Une variable proxy standard n'aide que si ce consommateur la lit ; ajouter des variables de nom similaire ne prouve pas la prise en charge.
3. Suivez la route réelle de l'artefact. Les serveurs de publication, les stockages d'objets et les cibles de redirection peuvent différer du registre. Comparez l'authentification proxy, les destinations approuvées et la confiance TLS pour la requête qui a échoué.

Faites-le avant de vider les caches : la transition du journal entre la récupération du paquet et l'exécution du cycle de vie circonscrit déjà la panne. Un accès réussi au registre est une preuve comparative utile, mais il n'établit pas que le programme secondaire prend en charge la même route ni qu'il peut atteindre son hôte d'artefacts.

Désactiver les scripts d'installation peut sauter le téléchargement et laisser le paquet inutilisable. Si le paquet documente une voie d'installation approuvée, précompilée ou hors ligne, préparez cet artefact délibérément et confirmez que l'exécutable est disponible avant de considérer l'installation terminée.