Yarn: Une erreur inattendue s'est produite: la demande a échoué \ "404 Not Found \" ".

En passant, le package existe clairement et yarn accède clairement au package d'une manière ou d'une autre parce que l'URL contient le numéro de version qu'elle tente de récupérer.

Après avoir exécuté quelques tests supplémentaires, j'ai constaté que le même package ne s'installait pas à partir d'autres référentiels qui le nécessitaient lors de l'utilisation de Yarn . Cependant, cela fonctionne bien lorsque vous utilisez npm .

Cela m'amène à penser que ce n'est pas ma configuration spécifique au référentiel. Cela pourrait-il être quelque chose à voir avec le nom du paquet qui déclenche Yarn vers le haut, ou le codage de l'url ou quelque chose?

S'accrochant à des pailles ici, mais j'espère que cela pourrait pousser quelqu'un dans la bonne direction

J'ai corrigé ceci: j'ai simplement republié le package incriminé avec un nouveau numéro de version.

Je ne sais pas pourquoi cela a résolu le problème.

Je laisserai ceci ici au cas où cela faciliterait le débogage.

Je rencontre le même problème. Cela semble se produire au hasard et est souvent résolu en réessayant simplement la construction.

Nous rencontrons également exactement le même problème.
Certains modules privés fonctionnent, d'autres non; tout de même @scope.

Nous venons de rencontrer le même problème. Un peu plus de contexte ici dans l'espoir que cela pourrait aider

• Nous utilisions du fil dans notre CI (Drone), qui fonctionne dans des conteneurs Docker éphémères [Alpine Linux]
• Le problème s'est produit dans UN SEUL de nos bâtiments de services, alors que rien ne s'est mal passé avec les autres services, même s'ils ont exactement la même arborescence de dépendances (!)
• une installation manuelle sur mon Mac pour le même dépôt n'a donné aucun problème (!)
• le problème était limité à un seul package privé

Comme mentionné ci-dessus comme solution de contournement, la publication d'une nouvelle version du package a résolu le problème.

Malheureusement, je n'ai pas pu obtenir un yarn-error.log détaillé car les conteneurs sont détruits immédiatement après l'échec d'une compilation. Si quelqu'un d'autre a ce problème, pourriez-vous réessayer avec une installation verbose et lancer le journal ici?

Je vois le même problème. J'utilise une image docker dans circleci 2.0 et j'ai des problèmes non liés que je débogue localement (différence de compilation sur cci vs local).

• quand je yarn sur la machine OSX hôte, tout fonctionne.
• quand je yarn sur le conteneur (Ubuntu), j'obtiens l' erreur .
• quand je yarn sur le conteneur ^^ (Ubuntu) fonctionnant sur l'infrastructure circleci 2.0, cela fonctionne.

J'ai configuré .npmrc etc. C'est vraiment un scratcher que cela ne fonctionne pas pour moi sur un conteneur fonctionnant localement.

Verbose ne m'a fourni aucune information que je puisse repérer:

root<strong i="17">@2adc7c09ff9a</strong>:~/af/spec/dummy# yarn --pure-lockfile --ignore-optional
yarn install v0.21.3
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@alienfast/build/-/build-2.0.38.tgz: Request failed \"404 Not Found\"".
info If you think this is a bug, please open a bug report with the information provided in "/root/af/spec/dummy/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
root<strong i="18">@2adc7c09ff9a</strong>:~/af/spec/dummy# yarn --pure-lockfile --ignore-optional --verbose
yarn install v0.21.3
verbose 0.178 current time: 2017-03-01T20:22:52.715Z
[1/4] Resolving packages...
[2/4] Fetching packages...
verbose 0.798 Performing "GET" request to "https://registry.yarnpkg.com/@alienfast/build/-/build-2.0.38.tgz".
verbose 0.861 Performing "GET" request to "https://registry.yarnpkg.com/@alienfast/ui/-/ui-1.0.34.tgz".
verbose 0.894 Performing "GET" request to "https://registry.yarnpkg.com/react-relay/-/react-relay-0.10.0.tgz".
verbose 0.895 Performing "GET" request to "https://registry.yarnpkg.com/react-dom/-/react-dom-15.4.2.tgz".
verbose 0.919 Performing "GET" request to "https://registry.yarnpkg.com/eslint/-/eslint-3.15.0.tgz".
verbose 0.941 Performing "GET" request to "https://registry.yarnpkg.com/flow-bin/-/flow-bin-0.39.0.tgz".
verbose 0.951 Performing "GET" request to "https://registry.yarnpkg.com/@alienfast/material-ui/-/material-ui-0.16.87.tgz".
verbose 0.966 Performing "GET" request to "https://registry.yarnpkg.com/@alienfast/react-formal/-/react-formal-0.24.7.tgz".
verbose 1.003 Performing "GET" request to "https://registry.yarnpkg.com/babel-runtime/-/babel-runtime-6.23.0.tgz".
verbose 1.103 Performing "GET" request to "https://registry.yarnpkg.com/graphql/-/graphql-0.9.1.tgz".
verbose 1.178 Performing "GET" request to "https://registry.yarnpkg.com/lodash/-/lodash-4.17.4.tgz".
verbose 1.206 Performing "GET" request to "https://registry.yarnpkg.com/material-ui/-/material-ui-0.16.7.tgz".
verbose 1.249 Performing "GET" request to "https://registry.yarnpkg.com/react-i18next/-/react-i18next-2.2.0.tgz".
verbose 1.261 Performing "GET" request to "https://registry.yarnpkg.com/react-relay-network-layer/-/react-relay-network-layer-1.4.0.tgz".
verbose 1.272 Performing "GET" request to "https://registry.yarnpkg.com/react-router/-/react-router-3.0.2.tgz".
verbose 1.696 Performing "GET" request to "https://registry.yarnpkg.com/react-router-relay/-/react-router-relay-0.13.5.tgz".
verbose 1.764 Performing "GET" request to "https://registry.yarnpkg.com/react-sizeme/-/react-sizeme-2.2.0.tgz".
verbose 2.063 Performing "GET" request to "https://registry.yarnpkg.com/recompose/-/recompose-0.22.0.tgz".
verbose 2.144 Error: https://registry.yarnpkg.com/@alienfast/build/-/build-2.0.38.tgz: Request failed "404 Not Found"
    at Request.handleRequestError (/root/.yarn/lib/fetchers/tarball-fetcher.js:231:20)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:189:7)
    at Request.onRequestResponse (/root/.yarn/node_modules/request/request.js:986:10)
    at emitOne (events.js:96:13)
    at ClientRequest.emit (events.js:189:7)
    at HTTPParser.parserOnIncomingClient (_http_client.js:522:21)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:99:23)
    at TLSSocket.socketOnData (_http_client.js:411:20)
    at emitOne (events.js:96:13)
    at TLSSocket.emit (events.js:189:7)
error An unexpected error occurred: "https://registry.yarnpkg.com/@alienfast/build/-/build-2.0.38.tgz: Request failed \"404 Not Found\"".
info If you think this is a bug, please open a bug report with the information provided in "/root/af/spec/dummy/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

root<strong i="21">@2adc7c09ff9a</strong>:~/af/spec/dummy# cat ~/.npmrc
registry=https://registry.npmjs.org/
//registry.npmjs.org/:_authToken=${NPM_TOKEN}

root<strong i="24">@2adc7c09ff9a</strong>:~/af/spec/dummy# echo $NPM_TOKEN
xxxxx-xxxx-xxxx-xxxx-xxxxxxxx

Idem ici, cela fonctionne localement sur OSX mais pas sur le conteneur CircleCI (circleci 1.0).

J'ai essayé de yarn cache clean - après l'installation d'un autre package a échoué.

Cela se produit avec yarn 0.18.1 ainsi que 0.21.3 - alors peut-être que quelque chose a changé dans la configuration du registre yarnpkg? Ou, puisque je pense que tout le monde dans les commentaires ici utilise CircleCI dans le scénario de problème, c'est un problème avec la configuration de CircleCI?

Donc, nous pensons que nous avons réussi à résoudre le problème; serait impatient de voir si cela fonctionne pour les autres:
Nous avons dû apporter un léger changement à .npmrc ce qui n'a guère de sens pourquoi cela fonctionne:

registry=http://registry.npmjs.org/
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
<strong i="8">@ourscope</strong>:registry=https://registry.npmjs.org/

Il convient de noter que nous avions besoin à la fois d'un registre normal ET d'un registre pour notre registre à portée privée. Assurez-vous simplement de changer @ourscope avec le vôtre.

Faites-moi savoir si cela aide quelqu'un.

@rogchap je viens d'essayer votre solution mais je vois toujours le même problème qu'avant :(

nous avons un trait d'union dans notre nom de portée, peut-être que cela pourrait être le coupable?

registry=http://registry.npmjs.org/
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
@our-scope:registry=https://registry.npmjs.org/

@rogchap cette solution de contournement n'a eu aucun effet sur notre situation.

root<strong i="7">@f41305331cb8</strong>:~/af/spec/dummy# cat ~/.npmrc
registry=https://registry.npmjs.org/
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
<strong i="8">@alienfast</strong>:registry=https://registry.npmjs.org/

Confirmé qu'il échoue avec 0.20.4 et 0.21.3 . Étant donné que cela a également fonctionné pour moi sans problème, je suis curieux de savoir si quelque chose a changé côté serveur pour provoquer cela. Cela ressemble certainement maintenant à un bug .

• Je viens de déployer de nouvelles versions des modules à portée «offensante» et cela n'a fait aucune différence, même erreur.
• J'ai couru npm install et je n'ai aucun problème à récupérer les modules dans l'environnement problématique

Donc, pas réglé pour moi ... encore une fois.

J'ai eu un autre module privé qui m'a donné le message 404, même s'il semble résoudre la bonne version (doit lire quelque chose correctement quelque part), et semble essayer de télécharger la même URL tar que NPM.

Cette fois, j'ai SUPPRIMÉ les registres (sauf celui d'authentification) dans .npmrc pour le faire fonctionner!

Il n'y a pas du tout de cohérence, "jouer" au hasard avec .npmrc semble fonctionner temporairement.

J'essaie de promouvoir Yarn, mais tous les ingénieurs de notre entreprise disent (à juste titre) que Yarn n'est "pas stable", "inutilisable", "pas fiable", "ne fonctionne pas avec des modules privés", "échoue sur le Serveur CI "etc. etc.

Je me demande si le registre Private NPM fait quelque chose de "funky" avec l'agent utilisateur! ?? <- Une supposition sauvage.

Afin de mieux comprendre cela, nous pouvons avoir besoin de la contribution des principaux contributeurs. @bestander , des idées?

Nous n'utilisons pas beaucoup de packages privés, donc cette fonctionnalité a moins d'attention.
Afaik la plupart des problèmes ont été résolus par la communauté.
C'est une excellente occasion d'essayer de résoudre ce problème.
Je ne pense pas que le registre npm ferait quelque chose avec la réponse basée sur UA, le jeton n'est probablement pas transmis du tout pour une raison quelconque.

D'accord, alors j'ai fourché du fil et j'ai joué un peu. Il semble qu'il perd le jeton avant de récupérer l'archive tar ou plutôt après l'envoi de la première requête ...

yarn add v0.23.0-0
verbose 0.227 current time: 2017-03-06T20:25:18.877Z
info No lockfile found.
[1/4] Resolving packages...
⠁ { authorization: 'Bearer MY_TOKEN_IS_HERE' } <<<<<----- here it uses my token for the request
verbose 0.409 Performing "GET" request to "https://registry.npmjs.org/@ovos-media%2flib-director".
verbose 1.306 Request "https://registry.npmjs.org/@ovos-media%2flib-director" finished with status code 200.
{} <--- token is gone
verbose 1.316 Performing "GET" request to "https://registry.npmjs.org/bluebird".
{} <--- token is gone
verbose 1.318 Performing "GET" request to "https://registry.npmjs.org/jwt-decode".
verbose 1.531 Request "https://registry.npmjs.org/bluebird" finished with status code 200.
verbose 1.572 Request "https://registry.npmjs.org/jwt-decode" finished with status code 200.
[2/4] Fetching packages...
https: /@ovos-media/lib-director/-/lib-director-0.4.1.tgz https://registry.yarnpkg.com/@ovos-media/lib-director/-/lib-director-0.4.1.tgz
{} <--- token is gone
verbose 1.597 Performing "GET" request to "https://registry.yarnpkg.com/@ovos-media/lib-director/-/lib-director-0.4.1.tgz".
verbose 2.663 Error: https://registry.yarnpkg.com/@ovos-media/lib-director/-/lib-director-0.4.1.tgz: Request failed "404 Not Found"
    at Request.res (/home/ubuntu/yarn/lib/fetchers/tarball-fetcher.js:232:20)
    at emitOne (events.js:90:13)
    at Request.emit (events.js:182:7)
    at Request.onRequestResponse (/home/ubuntu/yarn/node_modules/request/request.js:986:10)
    at emitOne (events.js:90:13)
    at ClientRequest.emit (events.js:182:7)
    at HTTPParser.parserOnIncomingClient (_http_client.js:469:21)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:103:23)
    at TLSSocket.socketOnData (_http_client.js:359:20)
    at emitOne (events.js:90:13)
error An unexpected error occurred: "https://registry.yarnpkg.com/@ovos-media/lib-director/-/lib-director-0.4.1.tgz: Request failed \"404 Not Found\"".

Lorsque je définis explicitement l'en-tête authorization dans le npm-registry.js avant l'envoi de la demande, tout fonctionne correctement. Il semble donc y avoir un bug dans le fil et pas du côté du serveur.

ÉDITER:

D'accord, donc après une inspection plus approfondie, ce problème se produit car la vérification si l'en-tête d'autorisation doit être défini renvoie false dans npm-registry.js -> https://github.com/yarnpkg/yarn/pull/2598/files#diff -b053bee294c216269844e5874039b6caR62
Et cela, à son tour, se produit parce qu'il compare le proxy de registre yarnpkg avec le registre npmjs.

https://registry.yarnpkg.com/@ovos-media/lib-director/-/lib-director-0.4.1.tgz https://registry.npmjs.org/

D'accord, j'ai donc compris comment résoudre ce problème pour nous sans modifier le code source des fils.
C'est essentiellement ce que @rogchap a publié mais (dans notre cas) dans l'autre sens:

registry=https://registry.npmjs.org/
@ovos-media:registry=https://registry.yarnpkg.com/
//registry.npmjs.org/:_authToken=your-auth-token

OU bien se débarrasser complètement du registre:

//registry.npmjs.org/:_authToken=your-auth-token

Cela semble fonctionner car yarn n'utilise pas de registres différents pour le paquet en question pour récupérer des informations et des archives tar. Cependant, je ne sais pas pourquoi le fil mélange ces deux éléments et je pense que la vérification du jeton d'authentification pourrait être modifiée / améliorée d'une manière ou d'une autre.

Quelle est la prochaine étape?
Documenter la solution de contournement ou apporter des modifications à Yarn?

J'ai essayé toutes les combinaisons possibles au cours des dernières heures et je pense qu'il est prudent de dire qu'il n'y a pas de solution de contournement fiable pour ce problème. @flipace une idée si c'est quelque chose qui peut être corrigé facilement? Vos deux méthodes ne fonctionnent pas pour moi :(.

En fait, grattez ça, ça le fait. Supprimer les attributions de registre et ne conserver que la ligne avec le jeton d'authentification semble faire l'affaire. Putain de fautes de frappe. Merci @flipace!

@bestander J'essaierai de trouver un PR dans les prochains jours, le comportement du fil dans ce cas n'est pas ce qu'il devrait être. Merci @pleunv d' avoir confirmé que la solution de contournement fonctionne aussi pour vous!

La solution de contournement ne fonctionne pas pour moi malheureusement 😿

@willrstern pourriez-vous publier votre .npmrc peut-être?

Ah, supprimer .yarnrc fonctionné pour moi. Le contenu était:

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


registry "https://registry.npmjs.org/"
email <email>
lastUpdateCheck 1489181224804
username <username>

notez que le registre npmjs.org était quelque chose que j'avais ajouté lors du dépannage pour savoir pourquoi il ne fonctionnait pas, donc ce n'était pas la configuration incriminée.

@flipace .npmrc était toutes les solutions de contournement ci-dessus, y compris la ligne de jeton uniquement.

~ Aucune de ces solutions de contournement n'a fonctionné pour moi. ~

En fait, cela fonctionne si je mets ceci dans mon fichier docker:

RUN echo -e "registry=https://registry.npmjs.org/\n//registry.npmjs.org/:_authToken=\${NPM_AUTH_TOKEN}\nsatoshipay:registry=https://registry.npmjs.org/" > /usr/src/app/.npmrc
RUN yarn

La portée en question pour moi est @satoshipay

Un collègue et moi avons eu ce problème ... après l'installation du nœud v7.7.4 et la reconnexion à npm via npm login , tout a fonctionné.

@Levino Pouvez-vous lancer yarn config list et voir si yarn récupère le fichier .npmrc? Dans # 521, @BohdanTkachenko a résolu le problème de la même manière. Au moins cela fonctionne aussi pour moi :)

Juste un rappel que les relations publiques de la communauté sont les bienvenues, personne dans l'équipe principale ne se penche actuellement sur cela

@bestander Y a-t-il des pointeurs de l'équipe principale sur les problèmes potentiels?
Notre solution actuelle est de revenir à l'utilisation de npm 😞

Quelque part dans package-resolver ou package-fetcher.

Le mar 16 mai 2017 à 06:29, Roger Chapman [email protected]
a écrit:

@bestander https://github.com/bestander Y a-t-il des pointeurs du
équipe de base où se trouvent les problèmes?
Notre solution actuelle est de revenir à l'utilisation de npm 😞

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/2738#issuecomment-301679399 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ACBdWMCFoI3uXa_ROrI-ZqwvTGyJjUrhks5r6TQygaJpZM4MGvow
.

Pour tous ceux qui rencontrent ce problème, veuillez rechercher un fichier .npmrc dans le répertoire de votre projet ainsi que dans chaque répertoire parent au-dessus. S'il en existe un, il remplacera le fichier .npmrc dans votre répertoire personnel. Un membre de mon équipe a rencontré ce problème. Il avait un jeton différent dans un fichier .npmrc différent.

J'ai aussi un autre endroit à chercher. Nous avons généralement ces problèmes avec yarn install et l'utilisation de packages privés étendus dans CI . Hier, j'ai eu à nouveau le problème. Le membre de l'équipe qui a créé le nouveau service n'a pas configuré registry.npmjs.org comme registre pour l'étendue dans son .npmrc local. Cela a conduit au fait que le yarn.lock avait des liens registry.yarnpkg.com pour tous les packages, y compris ceux de portée. Curieusement, cela a fonctionné localement mais a éclaté en CI. J'ai donc supprimé le yarn.lock et l'ai recréé sur ma machine, où j'ai défini registry.npmjs.org pour la portée dans mon fichier .npmrc. Désormais, le fichier yarn.lock ne contenait que des liens vers registry.npmjs.org . J'ai poussé le nouveau yarn.lock et CI est passé sans aucun problème.

Je vous remercie!

Avoir .npmrc dans le cwd nous a également aidés sur gitlab-ci.

J'ai le même problème dans un conteneur docker + yarn 0.26.1 (l'installation fonctionne bien localement sur mon Mac).

.npmrc est:

<strong i="8">@binded</strong>:registry=https://registry.npmjs.com/
//registry.npmjs.org/:_authToken=${NPM_TOKEN}

NPM_TOKEN est correctement défini. Obtenir l'erreur suivante:

====>> cat .npmrc
  #!/bin/bash -eo pipefail
cat .npmrc
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
====>> build
  #!/bin/bash -eo pipefail
build
engines.node (package.json):  7
engines.npm (package.json):   unspecified (use default)
v7.10.0 is already installed.
Now using node v7.10.0 (npm v4.2.0)
default -> 7 (-> v7.10.0 *)
Using default npm version: 4.2.0
Resolving yarn version 0.26 via semver.io...
Downloading and installing yarn (0.26.1)...
Installed yarn 0.26.1
Installing node modules (yarn.lock)
yarn install v0.26.1
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@binded/binded-client/-/binded-client-1.3.2.tgz: Request failed \"404 Not Found\"".
info If you think this is a bug, please open a bug report with the information provided in "/ci/project/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Error: Exited with code 1
Step failed
Task failed

J'ai également essayé avec les .npmrc :

registry=http://registry.npmjs.org/
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
<strong i="16">@binded</strong>:registry=https://registry.npmjs.com/

Je ne sais pas si c'est pertinent, mais mes listes yarn.lock (il se résout comme https://registry.yarnpkg.com/... au lieu de https://registry.npmjs.com/... ):

"@binded/binded-client@^1.3.2":
  version "1.3.2"
  resolved "https://registry.yarnpkg.com/@binded/binded-client/-/binded-client-1.3.2.tgz#0c29ed98436084b39420020a533df26da3ebbda3"

mise à jour : si je supprime yarn.lock , l'installation réussit.
mise à jour : ressemble à l'installation de [email protected] corrigé mon problème (je pense que j'utilisais [email protected] avant)

@olalonde J'ai eu la même erreur. Définir le registre sur ma machine sur https://registry.npmjs.org/ et créer le yarn.lock résolu le problème pour moi.

Bonjour,

Depuis que j'ai eu le même problème et que j'ai réussi à le résoudre, je vais partager mon expérience.
J'ai essayé toutes les solutions random contournement @rogchap l'a dit - revenir à npm a fonctionné pour moi.

Après une installation réussie avec npm yarn install cessé de donner 404 Not Found .

Je n'ai aucune idée de ce qui s'est passé et comment cela a été corrigé.
Je vais garder un œil sur cette question. J'espère que quelqu'un résout ce mystère.

Meilleur,
pgergov

Ce problème se produit de manière aléatoire sur les versions de code. Des progrès ou des idées qu'est-ce qui cause cela?

Hé les gars, je voulais juste partager avec vous qu'en 0.27.5 le problème est résolu. Pour référence: https://github.com/yarnpkg/yarn/issues/3765
Ce problème semble désormais résolu.

Merci pour le suivi, @pgergov

J'ai également eu ce problème aujourd'hui. J'ai changé le registre en l'URL de l'archive tar github. Je n'ai pas pu trouver ce qu'était l'url de npmjs, alors j'ai essayé Github trouvé ici.
https://github.com/{USER}/{REPO}/tarball/{BRANCH}

Mettre ceci ici au cas où quelqu'un aurait le même problème que moi.

Je suis sur la dernière version 0.27.5. J'ai également rencontré l'erreur de fil 404 Not Found de la

@panalbish, vous pouvez essayer 0.28.2 ou essayer de mettre à jour votre jeton d'authentification pour voir si cela fonctionne.

@panalbish Merci pour la suggestion. Le déclassement à 0,27,3 a fonctionné.
@BYK J'ai essayé 0.28.2 et 0.28.4, ils ont tous deux échoué. J'obtiens une erreur quand il essaie de télécharger du code depuis github

yarn install v0.27.5
warning package.json: No license field
warning [email protected]: No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://codeload.github.com/soda0289/typescript-eslint-parser/tar.gz/840978a594dd659cfa2b40d8672ce7a742864623: Request failed \"404 Not Found\"".

Si je devais deviner, il envoie des jetons d'authentification au domaine github provoquant un 404. J'essaierai d'en examiner plus ce soir.

Il semble que ce problème couvre le problème:
https://github.com/yarnpkg/yarn/issues/3907

Duplicata de # 3907.

Il semble que supprimer yarn.lock avant d'exécuter la commande yarn (ou yarn install ) peut résoudre le problème pour moi.

Il semble que supprimer yarn.lock avant d'exécuter la commande yarn (ou yarn install) peut résoudre le problème pour moi.

Et puis vous devriez arrêter complètement d'utiliser du fil. Le fichier yarn.lock est le fichier qui garantit des "builds reproductibles". Vous ne voulez jamais supprimer cela.

OK calme toi. C'était à l'application elle-même que j'essayais d'utiliser.
Btw ne devrait pas package.json être suffisant pour se construire?

Techniquement oui. Le fichier de verrouillage garantit que vous utiliserez les mêmes versions que tout le monde dans l'équipe. Si pour une raison quelconque vous ne vous souciez pas, vous pouvez supprimer le fichier de verrouillage et Yarn en créera un nouveau à partir de zéro.

Cela étant dit, il est curieux que cela ait résolu votre problème, car celui que nous suivons ici est lié à un paramètre de configuration. Peut-être que votre fichier de verrouillage faisait référence à une URL qui avait été supprimée depuis? Un commit git qui a été supprimé via une poussée forcée, peut-être?

Voici le message que j'ai reçu:

vagrant @ homestead : ~ / Projects / l5b.dev $ yarn
fil installer v0.27.5
[1/4] Résolution des packages ...
[2/4] Récupération des packages ...
erreur Une erreur inattendue s'est produite: " https://registry.yarnpkg.com/webpack-dev-server/-/webpack-dev-server-2.7.0.tgz : La demande a échoué \" 404 Not Found \ ""

J'ai essayé à nouveau d'installer le référentiel qui est l'application Laravel ( étapes d'installation ). npm a bien fonctionné à la fois sur localhost (vagrant) et en ligne, mais le fil a généré cette erreur.

Eh bien, ne cherchez plus:

Pas de chance sur npm non plus:

Peut-être que l'organisation Webpack a décidé d'annuler cette version après l'avoir installée.

Hm, npm install installation terminée bien que de nombreux avertissements. Mais les avertissements ne sont pas des erreurs.
J'essaye toujours d'attraper ces choses JS. Je me suis tenu à l'ère de jQuery et j'ai besoin d'accélérer.

OK calme toi. C'était à l'application elle-même que j'essayais d'utiliser.

Je ne voulais pas offenser. Je suis désolé si on en a pris.

Btw ne devrait-il pas que package.json soit suffisant pour se construire?

Vous voudrez peut-être lire ceci: https://www.sitepoint.com/yarn-vs-npm/ et permettez-moi de souligner le paragraphe le plus intéressant:

Le fichier yarn.lock
Dans package.json, le fichier dans lequel npm et Yarn assurent le suivi des dépendances du projet, les numéros de version ne sont pas toujours exacts. Au lieu de cela, vous pouvez définir une plage de versions. De cette façon, vous pouvez choisir une version majeure et mineure spécifique d'un paquet, mais autorisez npm à installer le dernier correctif qui pourrait corriger certains bogues.
Dans un monde idéal de versionnage sémantique, les versions corrigées n'incluront aucune modification de rupture. Ceci, malheureusement, n'est pas toujours vrai. La stratégie employée par npm peut résulter en deux machines avec le même fichier package.json, ayant différentes versions d'un package installées, introduisant éventuellement des bogues.
Pour éviter les erreurs de correspondance de version du package, une version installée exacte est épinglée dans un fichier de verrouillage. Chaque fois qu'un module est ajouté, Yarn crée (ou met à jour) un fichier yarn.lock. De cette façon, vous pouvez garantir qu'une autre machine installe exactement le même package, tout en ayant toujours une plage de versions autorisées définies dans package.json.
Dans npm, la commande npm shrinkwrap génère également un fichier de verrouillage, et npm install lit ce fichier avant de lire package.json, un peu comme la façon dont Yarn lit d'abord yarn.lock. La différence importante ici est que Yarn crée et met toujours à jour yarn.lock, tandis que npm n'en crée pas un par défaut et ne met à jour npm-shrinkwrap.json que lorsqu'il existe.

Donc, si vous ne vous souciez pas d'épingler des versions pour éviter les constructions "aléatoires", au lieu de supprimer le fichier yarn.lock et d'exécuter yarn vous devez laisser le fichier en place et utiliser npm install (qui ignorera le fichier yarn.lock )

Votre projet est-il en ligne quelque part?

@Tpojka essaie de supprimer le fichier yarn.lock et le node_modules localement (!), Puis exécutez yarn localement. Ensuite, validez le nouveau fichier yarn.lock et voyez si cela aide

Contexte: Cela changera la version épinglée de votre package manquant par la dernière version toujours compatible avec la plage de versions définie dans le package.json . Si celui qui est actuellement épinglé dans votre yarn.lock n'a pas été publié, le nouveau devrait être là.

Oui, j'utilise yarn 0.18 depuis longtemps à cause de ce problème étrange et je peux confirmer qu'une suppression-recréation unique de yarn.lock semble résoudre le problème. Donc, d'une manière ou d'une autre, il est lié aux fichiers de verrouillage de l'ancienne version de fil pour autant que je sache.

@sottbessler, malheureusement, cela semble aléatoire. Parfois, un retrait du fil.lock fonctionne, parfois non. Il se passe autre chose de bizarre. Il peut résoudre le paquet (car il sait quelle version télécharger) mais 404 du fichier tar.

Face à ce problème, a travaillé sur ma machine mac, mais pas sur le serveur.

Fonctionne avec yarn v1.0.1 (pour nous localement, sur CI et dans Heroku buildpack) en suivant https://github.com/yarnpkg/yarn/issues/3765#issuecomment -327890328 et https://github.com/yarnpkg / yarn / issues / 3765 # issuecomment -328207599.

always-auth=true
https://registry.npmjs.org/:_authToken=${NPM_TOKEN}

J'ai toujours un problème ici.

J'ai essayé d'ajouter always-auth=true à mon fichier .npmrc . J'ai également essayé d'ajouter un https: explicite devant //registry.npmjs.org/:_authToken=... . Cela ne faisait aucune différence non plus.

Les choses fonctionnent très bien pour Yarn 0.27.3 , mais tout ce que 1.0.0 + semble avoir ce problème (j'utilise actuellement yarn 1.2.1 ).

Est-ce que j'ai râté quelque chose?

Essayez de tout supprimer de .npmrc sauf //registry.npmjs.org/:_authToken=${NPM_TOKEN} . C'est la seule chose qui fonctionne de manière cohérente pour nous avec nos packages privés @ -scoped (Unix / Windows / OSX) sur yarn 1.0.0+.

@pleunv Merci! Cela a fonctionné pour moi en utilisant Yarn 1.3.2 , mais seulement si j'ai également exécuté cette commande:

yarn config set registry https://registry.npmjs.org

Mon impression était que le registre Yarn par défaut n'était qu'un proxy pour npmjs.org. Je ne sais donc pas pourquoi cela devrait être nécessaire, mais c'est absolument dans mon cas (testé avec et sans).

Je ne peux pas croire que plus de gens n'aient pas de problèmes avec ça. J'aurais pensé que chaque projet non open source trébucherait là-dessus?!?

Je n'ai testé cela que lors de déploiements ( c'est- à- Dockerfile faisant une compilation). Je vais bientôt l'essayer sur ma machine de développement (mes efforts pour comprendre cela ce matin m'ont coûté plus d'une heure 😢).

@pleunv @xogeny pouvez-vous nous fournir un petit cas de repro afin que nous puissions résoudre ce problème une fois pour toutes? Il est très difficile de retracer cela pour nous :(

@BYK sauf si je manque quelque chose, un tel cas de test nécessiterait, par nécessité, un dépôt privé et pour réussir à tester yarn nous aurions besoin de partager un jeton d'accès privé. Cela semble au mieux gênant.

Il semble que la meilleure approche serait pour le projet Yarn lui-même d'établir des référentiels privés (via un compte organisationnel minimal et bon marché) afin que vous puissiez effectuer ces tests en fournissant un jeton d'accès via une variable d'environnement via CircleCI ou votre développeur local / environnement de test. De cette façon, ce serait votre jeton et vous n'auriez pas besoin de le partager avec qui que ce soit.

Mais je suis ouvert à d'autres suggestions. Je ne sais tout simplement pas comment organiser les choses.

Ouais, la portée privée rend cela un peu difficile de vous fournir une repro. Quoi qu'il en soit, nous avions cela sur notre CI avec n'importe quel package à portée privée, sur le conteneur docker nodeJS par défaut.

@BYK Je peux mettre en place une version d'essai d'un référentiel Bintray npm avec un repro-repo qui l'accompagne et vous envoyer la clé d'accès par courrier si cela peut aider.

@SpainTrain Merci beaucoup, réglage

always-auth=true
<strong i="7">@scope</strong>:always-auth=true

en haut de .npmrc corrigé avec yarn v1.3.2

Dans ma situation, le problème a disparu lorsque j'ai mis yarn.lock jour npmjs.com au lieu de yarnpkg.com comme ça -

"@myco/pak1@>=0.0.8":
  version "0.0.11"
  resolved "https://registry.yarnpkg.com/@myco/pak1/-/pak1-0.0.11.tgz#8b5c53bd7378d7f00554fd4813ad9d332d0d87dc"
                             ^^^^^^^ change this
  resolved "https://registry.npmjs.com/@myco/pak1/-/pak1-0.0.11.tgz#8b5c53bd7378d7f00554fd4813ad9d332d0d87dc"
  dependencies:
    lodash "4.*"

Aucune de ces solutions n'a fonctionné pour moi. Nous n'utilisons même pas un package privé, juste un fork public d'un package public. Changement de yarn.lock pour faire référence à npmjs.com, utilisé le paramètre de registre yarn avant l'étape d'installation de yarn.

CircleCI obtient juste des 404 par intermittence sur les urls github "codeload" pendant l'étape d'installation de fil pour une raison quelconque.

Je peux également confirmer qu'après avoir exécuté yarn config set registry https://registry.npmjs.org comme @xogeny l'a suggéré, yarn add @org/priv-module ne sont plus 404 et installe correctement le paquet.

Cependant, voici la partie intéressante - je suis revenu au registre d'origine ( yarn config set registry https://registry.yarnpkg.com ), j'ai refait rm -rf *; yarn cache clean et yarn add @org/priv-module , je ne pouvais plus reproduire le 404, c'est-à-dire qu'il était installé correctement. Je suis sûr que je ne suis pas fou ici - yarn add @org/priv-module fait 404 la toute première fois.

Comment exactement registry.yarnpkg.com proxy registry.npmjs.org ? Vous avez l'impression qu'un cache a été rempli après une récupération réussie?

Je suis sur v1.3.4 sur macOS 10.13.2, et .npmrc est tout simplement 'ol //registry.npmjs.org/:_authToken={auth token}

Même problème ici. Voici un journal de TravisCI

$ node --version
v8.9.4
$ npm --version
5.6.0
$ nvm --version
0.33.8
before_install.1
0.42s$ yarn config set registry https://registry.npmjs.org
yarn config v1.3.2
success Set "registry" to "https://registry.npmjs.org".
before_install.2
0.43s$ yarn cache clean
yarn cache v1.3.2
success Cleared cache.
$ yarn
yarn install v1.3.2
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/pinkie-promise/-/pinkie-promise-2.0.1.tgz: Request failed \"404 Not Found\"".
info If you think this is a bug, please open a bug report with the information provided in "/home/travis/build/grundiss/contenter/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Chose amusante: localement, tout fonctionne très bien.

juste pour terminer, voici quelques constructions de circleci qui ont échoué, et le paquet 404 n'est pas toujours le même:

https://circleci.com/gh/EnoahNetzach/gnodsidfjgi/5
https://circleci.com/gh/EnoahNetzach/gnodsidfjgi/7

J'ai (espérons-le) résolu mon problème en suivant ces instructions et en créant un miroir hors ligne, mais ce n'est certainement pas la voie à suivre.

Sensationnel. Il s'est avéré que mon problème ne faisait pas partie de ce problème, mais plutôt une partie d'une chose plus globale: https://github.com/floatdrop/pinkie/issues/18

Merde, maintenant nous avons aussi commencé à avoir ce problème. Forfait à portée privée. Reproduction aléatoire - fonctionne parfois (avec certaines versions), parfois non.

Voir cette erreur sur notre projet. C'est bizarre, car je n'obtiens pas de 404 lorsque je frappe l'URL manuellement:

Trace:
  Error: https://codeload.github.com/types/npm-v8flags/tar.gz/de224ae1cd5fd7dbb4e7158a6cc7a29e5315930d: Request failed "404 Not Found"
      at Request.handleRequestError (C:\Users\stewx\AppData\Roaming\nvm\v6.10.0\node_modules\yarn\lib\fetchers\tarball-fetcher.js:203:20)
      at emitOne (events.js:96:13)
      at Request.emit (events.js:188:7)
      at Request.onRequestResponse (C:\Users\stewx\AppData\Roaming\nvm\v6.10.0\node_modules\yarn\node_modules\request\request.js:1068:10)
      at emitOne (events.js:96:13)
      at ClientRequest.emit (events.js:188:7)
      at HTTPParser.parserOnIncomingClient (_http_client.js:474:21)
      at HTTPParser.parserOnHeadersComplete (_http_common.js:99:23)
      at TLSSocket.socketOnData (_http_client.js:363:20)
      at emitOne (events.js:96:13)

Nous avons résolu toutes les erreurs comme celles-ci en changeant un peu nos URL. Évitez tar / gz et utilisez tarball, c'est-à-dire:

"package_name":"https://github.com/somebody/package_name/tarball/master"

Si votre paquet est hébergé en privé sur npmjs.org, la suppression de la ligne <strong i="5">@scope</strong>:registry=https://registry.npmjs.org/ de .npmrc a fonctionné pour nous - cela est probablement dû à des problèmes avec yarnpkg étant un CDN pour npmjs.org

Je l'expose aujourd'hui
error An unexpected error occurred: “https://registry.yarnpkg.com/@types/webpack/-/webpack-3.8.10.tgz: Request failed \“404 Not Found\“”.
Pas un dépôt privé :(

+1 pour moi. J'ai commencé à en faire l'expérience aujourd'hui. Essayer d'installer le webpack sur notre CI.

Même chose ici lol. Essayé le plus récent

error An unexpected error occurred: "https://registry.yarnpkg.com/@types/webpack/-/webpack-4.1.1.tgz: Request failed \"404 Not Found\"".

Il est discuté ici https://github.com/yarnpkg/yarn/issues/5530

Dans mon cas, j'avais un .npmrc local qui définissait un registre privé pour une portée spécifique, tout ce que j'avais à ajouter était registry=https://registry.npmjs.org/ en haut du fichier. Résultant en:

# .npmrc
registry=https://registry.npmjs.org/

<strong i="8">@acme</strong>:registry=https://acme.jfrog.io/acme/api/npm/npm/
//acme.jfrog.io/acme/api/npm/npm/:_auth=YYYYYYYYYYYYYYYYYYYYYYYYYY
//acme.jfrog.io/acme/api/npm/npm/:username=username
//acme.jfrog.io/acme/api/npm/npm/:[email protected]
//acme.jfrog.io/acme/api/npm/npm/:always-auth=true

Travailler avec CircleCI avait également 404 avec installation de fil.

retirer yarn.lock

Cela a fonctionné pour moi. En creusant un peu plus, j'ai découvert qu'il y avait de mauvaises URL dans le verrou de fil.

Le verrou de fil utilisait registry.yarnpkg.com qui serait 404 sur CircleCI (aucune idée de pourquoi cela fonctionnait localement).

La configuration résultante qui a fait l'affaire:

- run: echo "//registry.npmjs.org/:_authToken=$NPM_AUTH_TOKEN" > ~/.npmrc
- run: yarn config set registry https://registry.npmjs.org/
- run: yarn

Merci à tous, j'ai moi aussi résolu ce problème en supprimant yarn.lock.

Pour moi, la commande qui a échoué était yarn add gatsby-plugin-react-helmet react-helmet .

J'ai pu exécuter un yarn upgrade (essayé par curiosité), puis la commande ci-dessus a fonctionné. Je ne sais pas pourquoi, mais je serais reconnaissant si quelqu'un avait une explication.

peut-être que npm est nécessaire car la dépendance n'est pas disponible sur les référentiels de fils

ont le même problème avec le fil + CI + matériel

yarn install v1.22.4
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@material-ui/core/-/core-4.11.0.tgz: Request failed \"404 Not Found\"".
info If you think this is a bug, please open a bug report with the information provided in "/builds/springs-apps/flopanda/flopanda-front-end/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.