Yarn: Ein unerwarteter Fehler ist aufgetreten: Anforderung fehlgeschlagen "404 nicht gefunden".

Abgesehen davon ist das Paket eindeutig vorhanden und yarn greift eindeutig auf das Paket zu, da die URL die Versionsnummer enthält, die abgerufen werden soll.

Nachdem ich einige weitere Tests durchgeführt habe, habe ich festgestellt, dass dasselbe Paket nicht aus anderen Repositorys installiert werden kann, die es benötigen, wenn Yarn . Es funktioniert jedoch einwandfrei, wenn npm .

Dies lässt mich denken, dass es nicht meine Repository-spezifische Konfiguration ist. Könnte es etwas mit dem Namen des Pakets zu tun haben, das Yarn auslöst, oder mit der URL-Codierung oder so?

Hier an Strohhalmen festhalten, aber hoffentlich könnte dies jemanden in die richtige Richtung stoßen

Ich habe dies behoben: Ich habe das fehlerhafte Paket einfach mit einer neuen Versionsnummer erneut veröffentlicht.

Ich habe keine Ahnung, warum das behoben wurde.

Ich werde dies hier belassen, falls es das Debuggen unterstützt.

Ich habe das gleiche Problem. Dies scheint zufällig zu geschehen und wird häufig durch einfaches Wiederholen des Builds behoben.

Wir haben auch genau das gleiche Problem.
Einige private Module funktionieren, andere nicht. egal @scope.

Wir haben gerade das gleiche Problem erlebt. Etwas mehr Kontext hier in der Hoffnung, dass es helfen könnte

• Wir haben Garn in unserer CI (Drone) ausgeführt, die in kurzlebigen Docker-Containern ausgeführt wird [Alpine Linux]
• Das Problem trat nur in EINEM unserer Servicegebäude auf, während bei den anderen Services nichts schief gelaufen ist, obwohl sie genau denselben Abhängigkeitsbaum haben (!).
• Eine manuelle Installation auf meinem Mac für dasselbe Repo brachte überhaupt keine Probleme (!)
• Das Problem war auf ein einziges privates Paket beschränkt

Wie oben als Problemumgehung erwähnt, wurde das Problem durch Veröffentlichen einer neuen Version des Pakets behoben.

Leider konnte ich kein detailliertes yarn-error.log da die Container sofort nach einem fehlgeschlagenen Build zerstört werden. Wenn jemand anderes dieses Problem hat, können Sie es mit einer Installation von verbose erneut versuchen und das Protokoll hier einwerfen?

Ich sehe das gleiche Problem. Ich verwende ein Docker-Image in circleci 2.0 und habe einige nicht verwandte Probleme, die ich lokal debugge (Kompilierungsunterschied zwischen cci und local).

• Wenn ich yarn auf dem Host-OSX-Computer habe, funktioniert alles.
• Wenn ich yarn auf dem Container (Ubuntu) habe, erhalte ich den Fehler .
• Wenn ich yarn auf dem ^^ Container (Ubuntu) habe, der auf der Circleci 2.0-Infrastruktur ausgeführt wird, funktioniert es.

Ich habe .npmrc usw. eingerichtet. Es ist wirklich ein Kratzer, dass es für mich auf einem lokal laufenden Container nicht funktioniert.

Verbose hat mir keine Informationen zur Verfügung gestellt, die ich erkennen kann:

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

Das gleiche gilt für OSX lokal, jedoch nicht für den CircleCI-Container (circleci 1.0).

Ich habe versucht, yarn cache clean - danach schlug die Installation eines anderen Pakets fehl.

Es passiert mit Garn 0.18.1 sowie 0.21.3 - also hat sich vielleicht etwas in der Konfiguration der Garnpkg-Registrierung geändert? Oder ist es ein Problem mit der CircleCI-Konfiguration, da ich denke, dass jeder in den Kommentaren hier CircleCI im Problemszenario verwendet?

Wir glauben, wir haben es geschafft, das Problem zu lösen. würde gerne sehen, ob es für andere funktioniert:
Wir mussten eine geringfügige Änderung an .npmrc vornehmen, was wenig Sinn macht, warum dies funktioniert:

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

Zu beachten ist, dass wir sowohl eine normale Registrierung als auch eine für unsere private Registrierung benötigen. Stellen Sie einfach sicher, dass Sie @ourscope mit Ihren eigenen ändern.

Lassen Sie mich wissen, ob dies jemandem hilft.

@rogchap Ich habe gerade Ihre Lösung ausprobiert, sehe aber immer noch das gleiche Problem wie zuvor :(

Wir haben einen Bindestrich in unserem Bereichsnamen. Vielleicht könnte das der Schuldige sein.

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

@rogchap Diese

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/

Bestätigt, dass dies mit 0.20.4 und 0.21.3 fehlschlägt. Da dies auch bei mir problemlos funktioniert hat, bin ich gespannt, ob sich auf der Serverseite etwas geändert hat, um dies zu verursachen. Dies scheint jetzt sicherlich wie ein bug .

• Ich habe gerade neue Versionen der "beleidigenden" Module mit Gültigkeitsbereich bereitgestellt, und es machte keinen Unterschied, der gleiche Fehler.
• Ich habe npm install und habe keine Probleme beim Abrufen der Module in der Problemumgebung

Also nicht für mich repariert ... schon wieder.

Ich hatte ein anderes privates Modul, das mir die 404-Nachricht gab, obwohl es die richtige Version aufzulösen scheint (muss irgendwo etwas richtig lesen) und versucht, dieselbe Tar-URL wie NPM herunterzuladen.

Dieses Mal habe ich die Register (außer dem Auth) in .npmrc ENTFERNT , damit es funktioniert!

Es gibt überhaupt keine Konsistenz, zufälliges "Spielen" mit .npmrc scheint vorübergehend zu funktionieren.

Ich versuche, für Garn zu werben, aber jeder Ingenieur in unserem Unternehmen sagt (zu Recht), dass Garn "nicht stabil", "nicht verwendbar", "nicht zuverlässig", "funktioniert nicht mit privaten Modulen", "scheitert am" CI-Server "usw. usw.

Ich frage mich, ob die private NPM-Registrierung mit dem User-Agent etwas "Funky" macht! ?? <- Wilde Vermutung.

Um dies besser zu verstehen, benötigen wir möglicherweise einige Beiträge von wichtigen Mitwirkenden. @bestander , irgendwelche Einblicke?

Wir verwenden nicht viel private Pakete, daher hat diese Funktion weniger Augen.
Afaik die meisten Probleme wurden von der Community behoben.
Dies ist eine großartige Gelegenheit, um zu versuchen, das Problem zu beheben.
Ich glaube nicht, dass die npm-Registrierung etwas mit der auf UA basierenden Antwort anfangen würde, höchstwahrscheinlich wird das Token aus irgendeinem Grund überhaupt nicht übergeben.

Okay, also gabelte ich Garn und spielte ein bisschen herum. Es scheint, als ob es den Token verliert, bevor es den Tarball holt oder vielmehr nachdem die erste Anfrage gesendet wurde ...

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\"".

Wenn ich den authorization -Header in der Datei npm-registry.js explizit setze, bevor die Anforderung gesendet wird, funktioniert alles einwandfrei. Es scheint also einen Fehler im Garn zu geben und nicht auf der Serverseite.

BEARBEITEN:

Okay, nach weiterer Prüfung tritt dieses Problem auf, da die Überprüfung, ob der Autorisierungsheader gesetzt werden soll, in npm-registry.js -> https://github.com/yarnpkg/yarn/pull/2598/files#diff false zurückgibt -b053bee294c216269844e5874039b6caR62
Dies geschieht wiederum, weil der yarnpkg-Registrierungsproxy mit der npmjs-Registrierung verglichen wird.

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

Okay, also habe ich herausgefunden, wie ich dieses Problem für uns beheben kann, ohne den Quellcode des Garns zu ändern.
Es ist im Grunde das, was @rogchap gepostet hat, aber (in unserem Fall) in die andere Richtung:

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

ODER alternativ die Registrierung vollständig loswerden:

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

Dies scheint zu funktionieren, da Garn dann keine unterschiedlichen Register für das betreffende Paket verwendet, um Informationen und Tarballs abzurufen. Ich bin mir jedoch nicht sicher, warum Garn diese beiden mischt, und ich denke, dass die Überprüfung des Authentifizierungstokens möglicherweise irgendwie geändert / verbessert werden könnte.

Was ist der nächste Schritt?
Problemumgehung dokumentieren oder Änderungen an Garn vornehmen?

Ich habe in den letzten Stunden jede mögliche Kombination ausprobiert und ich kann mit Sicherheit sagen, dass es für dieses Problem keine zuverlässige Problemumgehung gibt. @flipace eine Idee, ob dies etwas ist, das leicht behoben werden kann? Beide Methoden funktionieren bei mir nicht :(.

Kratzen Sie das tatsächlich. Das Entfernen der Registrierungszuweisungen und das Beibehalten der Zeile mit dem Authentifizierungstoken scheint den Trick zu tun. Verdammte Tippfehler. Danke @flipace!

@bestander Ich werde versuchen, in den nächsten Tagen eine PR zu entwickeln. Das Verhalten von Garn ist in diesem Fall nicht so, wie es sein sollte. Vielen Dank an @pleunv für die Bestätigung, dass die

Die Problemumgehung funktioniert bei mir leider nicht 😿

@willrstern könntest du vielleicht deine .npmrc posten?

Ah, das Entfernen von .yarnrc hat bei mir funktioniert. Inhalt war:

# 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>

Beachten Sie, dass die npmjs.org -Registrierung etwas war, das ich bei der Fehlerbehebung hinzugefügt hatte, warum sie nicht funktionierte, also nicht die fehlerhafte Konfiguration.

@flipace .npmrc war eine der oben genannten Problemumgehungen, einschließlich der Nur-Token-Zeile.

~ Keine dieser Problemumgehungen hat bei mir funktioniert. ~

Eigentlich funktioniert es, wenn ich das in meine Docker-Datei lege:

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

Der für mich fragliche Bereich ist @satoshipay

Mitarbeiter und ich hatten dieses Problem ... Nachdem wir den Knoten v7.7.4 installiert und uns über npm login erneut bei npm angemeldet hatten, funktionierte alles.

@Levino Kannst du yarn config list ausführen und nachsehen, ob Garn die .npmrc-Datei aufnimmt? In # 521 löste @BohdanTkachenko das Problem ähnlich. Zumindest funktioniert das auch bei mir :)

Nur eine Erinnerung daran, dass PR aus der Community willkommen ist, untersucht derzeit niemand im Kernteam dies

@bestander Gibt es
Unsere aktuelle Problemumgehung besteht darin, wieder npm 😞 zu verwenden

Irgendwo im Paket-Resolver oder Paket-Abruf.

Am Dienstag, den 16. Mai 2017 um 06:29 Uhr, Roger Chapman [email protected]
schrieb:

@bestander https://github.com/bestander Gibt es Hinweise von der
Kernteam, wo die Probleme sein können?
Unsere aktuelle Problemumgehung besteht darin, wieder npm 😞 zu verwenden

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/2738#issuecomment-301679399 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/ACBdWMCFoI3uXa_ROrI-ZqwvTGyJjUrhks5r6TQygaJpZM4MGvow
.

Für alle, die dieses Problem haben, suchen Sie in Ihrem Projektverzeichnis nach einer .npmrc-Datei sowie in jedem darüber liegenden übergeordneten Verzeichnis. Wenn eine vorhanden ist, wird die .npmrc-Datei in Ihrem Home-Verzeichnis überschrieben. Ein Mitglied meines Teams ist auf dieses Problem gestoßen. Er hatte ein anderes Token in einer anderen .npmrc-Datei gesetzt.

Ich muss auch woanders suchen. Wir haben diese Probleme normalerweise mit yarn install und der Verwendung von privaten Paketen mit Gültigkeitsbereich in CI . Gestern hatte ich das Problem wieder. Das Teammitglied, das den neuen Dienst erstellt hat, hat registry.npmjs.org als Registrierung für den Bereich in seiner lokalen .npmrc konfiguriert. Dies führte zu der Tatsache, dass das Garn.lock registry.yarnpkg.com Links für alle Pakete hatte, einschließlich der Pakete mit Gültigkeitsbereich. Komischerweise funktionierte es vor Ort, brach aber in CI ein. Also habe ich die Datei yarn.lock gelöscht und auf meinem Computer neu erstellt, wo ich registry.npmjs.org für den Bereich in meiner .npmrc-Datei festgelegt habe. Jetzt hatte die Datei yarn.lock nur noch Links zu registry.npmjs.org . Ich schob das neue Garn.lock und CI ging ohne Probleme durch.

Vielen Dank!

Auch .npmrc im cwd zu haben, half uns bei gitlab-ci.

Ich habe das gleiche Problem in einem Docker-Container + yarn 0.26.1 (die Installation funktioniert lokal auf meinem Mac einwandfrei).

.npmrc ist:

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

NPM_TOKEN ist korrekt eingestellt. Erhalten folgenden Fehler:

====>> 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

Ich habe es auch mit folgenden .npmrc versucht:

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

Ich bin mir nicht sicher, ob das relevant ist, aber meine yarn.lock-Listen (es wird als https://registry.yarnpkg.com/... anstelle von 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"

Update : Wenn ich yarn.lock lösche, ist die Installation erfolgreich.
Update : Es sieht so aus, als hätte die Installation von [email protected] mein Problem behoben (ich glaube, ich habe zuvor [email protected] ).

@olalonde Ich hatte den gleichen Fehler. Das Setzen der Registrierung auf meinem Computer auf https://registry.npmjs.org/ und das Erstellen von yarn.lock löste das Problem für mich.

Hallo,

Da ich das gleiche Problem hatte und es geschafft habe, es zu lösen, werde ich meine Erfahrungen teilen.
Ich habe alle random Problemumgehungen ausprobiert , aber wie

Nach erfolgreicher Installation mit npm hat yarn install aufgehört, 404 Not Found .

Ich habe überhaupt keine Ahnung, was passiert ist und wie es behoben wurde.
Ich werde dieses Problem im Auge behalten. Hoffe, jemand löst dieses Rätsel.

Beste,
pgergov

Dieses Problem tritt zufällig bei Codeship-Builds auf. Irgendwelche Fortschritte oder Ideen, was das verursacht?

Hey Leute, wollte euch nur mitteilen, dass in 0.27.5 das Problem gelöst ist. Als Referenz: https://github.com/yarnpkg/yarn/issues/3765
Dieses Problem scheint jetzt zu schließen.

Vielen Dank für das Follow- up,

Ich hatte heute auch dieses Problem. Ich habe die Registrierung in die Github-Tarball-URL geändert. Ich konnte die URL von npmjs nicht finden, also habe ich versucht, Github hier zu finden.
https://github.com/{USER}/{REPO}/tarball/{BRANCH}

Setzen Sie dies hier ein, falls jemand das gleiche Problem hat wie ich.

Ich bin auf der neuesten Version 0.27.5. Ich habe auch den Fehler " Anfrage fehlgeschlagen 404 Nicht gefunden" gefunden . Ein Downgrade der Version auf 0.27.3 funktioniert.

@panalbish Sie können versuchen, 0.28.2 oder Ihr Authentifizierungstoken zu aktualisieren, um zu sehen, ob es funktioniert.

@panalbish Danke für den Vorschlag. Ein Downgrade auf 0,27,3 hat funktioniert.
@BYK Ich habe 0.28.2 und 0.28.4 ausprobiert, beide sind fehlgeschlagen. Ich erhalte eine Fehlermeldung, wenn versucht wird, Code von Github herunterzuladen

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\"".

Wenn ich raten müsste, ob es möglicherweise Authentifizierungstoken an die Github-Domäne sendet, die einen 404 verursachen. Ich werde versuchen, heute Abend mehr zu untersuchen.

Anscheinend deckt dieses Problem das Problem ab:
https://github.com/yarnpkg/yarn/issues/3907

Duplikat von # 3907.

Es scheint, dass das Entfernen von yarn.lock vor dem Ausführen des Befehls yarn (oder yarn install ) das Problem für mich beheben kann.

Es scheint, dass das Entfernen von yarn.lock vor dem Ausführen des Befehls yarn (oder yarn install) das Problem für mich beheben kann.

Und dann sollten Sie ganz aufhören, Garn zu verwenden. Die Datei yarn.lock ist die Datei, die "reproduzierbare Builds" garantiert. Das wollen Sie nie löschen.

Ok, beruhige dich. Es lag an der Anwendung selbst, die ich verwenden wollte.
Übrigens sollte package.json nicht ausreichen, um sich selbst zu erstellen?

Technisch ja. Die Sperrdatei garantiert, dass Sie dieselben Versionen verwenden wie alle anderen im Team. Wenn es Sie aus irgendeinem Grund nicht interessiert, können Sie die Sperrdatei entfernen und Yarn erstellt eine neue von Grund auf neu.

Abgesehen davon ist es merkwürdig, dass es Ihr Problem gelöst hat, da das hier verfolgte mit einem Konfigurationsparameter zusammenhängt. Vielleicht hat Ihre Sperrdatei auf eine URL verwiesen, die seitdem entfernt wurde? Vielleicht ein Git-Commit, das per Force-Push gelöscht wurde?

Dies ist die aktuelle Nachricht, die ich erhalten habe:

vagrant @ homestead : ~ / Projects / l5b.dev $ Garn
Garn installieren v0.27.5
[1/4] Pakete auflösen ...
[2/4] Pakete holen ...
Fehler Ein unerwarteter Fehler ist aufgetreten: " https://registry.yarnpkg.com/webpack-dev-server/-/webpack-dev-server-2.7.0.tgz : Anforderung fehlgeschlagen" 404 nicht gefunden "

Es wurde erneut versucht, das Repository zu installieren, bei dem es sich um eine Laravel-Anwendung handelt ( Installationsschritte ). npm funktionierte sowohl auf localhost (vagrant) als auch online einwandfrei, aber Garn gab diesen Fehler aus.

Nun, suchen Sie nicht weiter:

Auch bei npm kein Glück:

Möglicherweise hat die Webpack-Organisation beschlossen, diese Version nach der Installation zu löschen.

Hm, npm install die Installation abgeschlossen, obwohl es eine Reihe von Warnungen gibt. Warnungen sind jedoch keine Fehler.
Ich versuche immer noch, diese JS-Dinge zu fangen. Ich stand in der jQuery-Ära und muss beschleunigen.

Ok, beruhige dich. Es lag an der Anwendung selbst, die ich verwenden wollte.

Ich meinte keine Beleidigung. Es tut mir leid, wenn welche genommen wurden.

Übrigens sollte package.json nicht ausreichen, um sich selbst zu erstellen?

Vielleicht möchten Sie dies lesen: https://www.sitepoint.com/yarn-vs-npm/ und lassen Sie mich den interessantesten Absatz hervorheben:

Die Datei yarn.lock
In package.json, der Datei, in der sowohl npm als auch Yarn die Abhängigkeiten des Projekts verfolgen, sind die Versionsnummern nicht immer genau. Stattdessen können Sie eine Reihe von Versionen definieren. Auf diese Weise können Sie eine bestimmte Haupt- und Nebenversion eines Pakets auswählen, aber npm erlauben, den neuesten Patch zu installieren, der möglicherweise einige Fehler behebt.
In einer idealen Welt der semantischen Versionierung enthalten gepatchte Versionen keine wesentlichen Änderungen. Dies ist leider nicht immer der Fall. Die von npm verwendete Strategie kann dazu führen, dass zwei Computer mit derselben package.json-Datei unterschiedliche Versionen eines Pakets installiert haben und möglicherweise Fehler verursachen.
Um zu vermeiden, dass die Paketversion nicht übereinstimmt, wird eine genau installierte Version in einer Sperrdatei festgehalten. Jedes Mal, wenn ein Modul hinzugefügt wird, erstellt (oder aktualisiert) Yarn eine yarn.lock-Datei. Auf diese Weise können Sie garantieren, dass ein anderer Computer genau dasselbe Paket installiert, während in package.json immer noch eine Reihe zulässiger Versionen definiert sind.
In npm generiert der Befehl npm shrinkwrap auch eine Sperrdatei, und npm install liest diese Datei vor dem Lesen von package.json, ähnlich wie Yarn zuerst yarn.lock liest. Der wichtige Unterschied besteht darin, dass Yarn immer yarn.lock erstellt und aktualisiert, während npm standardmäßig keine erstellt und npm-shrinkwrap.json nur aktualisiert, wenn es vorhanden ist.

Wenn Sie sich also nicht darum kümmern, Versionen festzuhalten, um "zufällige" Builds zu vermeiden, sollten Sie die Datei an Ort und Stelle belassen und npm install , anstatt die Datei yarn.lock entfernen und yarn npm install (wodurch die Datei yarn.lock ignoriert wird)

Ist Ihr Projekt irgendwo online?

@Tpojka versucht, die yarn.lock -Datei und die node_modules lokal (!) Zu entfernen und dann yarn lokal auszuführen. Anschließend die neue Datei yarn.lock festschreiben und prüfen, ob dies hilfreich ist

Hintergrund: Dadurch wird die angeheftete Version Ihres fehlenden Pakets auf die neueste Version geändert, die noch mit dem in package.json definierten Versionsbereich kompatibel ist. Wenn der aktuell in Ihrem yarn.lock angeheftete nicht veröffentlicht wurde, sollte der neue vorhanden sein.

Ja, ich habe wegen dieses seltsamen Problems schon lange Garn 0.18 verwendet und kann bestätigen, dass eine einmalige Entfernung und Wiederherstellung von Garn.lock das Problem zu lösen scheint. Soweit ich das beurteilen kann, hängt es also irgendwie mit den Sperrdateien der alten Garnversion zusammen.

@sottbessler leider scheint dies zufällig. Manchmal funktioniert das Entfernen des Garns. Schloss funktioniert, manchmal nicht. Es ist noch etwas Seltsames los. Es kann das Paket auflösen (da es weiß, welche Version heruntergeladen werden muss), aber 404 der TAR-Datei.

Konfrontiert mit diesem Problem, arbeitete auf meinem Mac-Computer, aber nicht auf dem Server.

Funktioniert in Garn v1.0.1 (für uns lokal, auf CI und im Heroku-Buildpack) unter https://github.com/yarnpkg/yarn/issues/3765#issuecomment -327890328 und https://github.com/yarnpkg / yarn / issue / 3765 # issuecomment -328207599.

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

Ich habe hier immer noch ein Problem.

Ich habe versucht, always-auth=true zu meiner .npmrc -Datei hinzuzufügen. Ich habe auch versucht, ein explizites https: vor //registry.npmjs.org/:_authToken=... . Das machte auch keinen Unterschied.

Die Dinge funktionieren gut für Garn 0.27.3 , aber alles, was 1.0.0 + ist, scheint dieses Problem zu haben (ich verwende derzeit Garn 1.2.1 ).

Vermisse ich hier etwas?

Versuchen Sie, alles aus .npmrc entfernen, außer //registry.npmjs.org/:_authToken=${NPM_TOKEN} . Dies ist das einzige, was für uns mit unseren privaten @ -scoped-Paketen (Unix / Windows / OSX) auf Garn 1.0.0+ konsistent funktioniert.

@pleunv Danke! Das hat bei mir mit Yarn 1.3.2 funktioniert, aber nur, wenn ich auch diesen Befehl ausgeführt habe:

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

Mein Eindruck war, dass die Standard-Garnregistrierung nur ein Proxy für npmjs.org war. Ich bin mir also nicht sicher, warum dies notwendig sein sollte, aber es ist absolut in meinem Fall (getestet mit und ohne).

Ich kann nicht glauben, dass mehr Leute keine Probleme damit haben. Ich hätte gedacht, dass jedes Nicht-Open-Source-Projekt darüber stolpern würde?!?

Ich habe dies nur bei Bereitstellungen getestet ( dh innerhalb eines Dockerfile , der einen Build ausführt). Ich werde es bald auf meiner Entwicklungsmaschine versuchen (meine Bemühungen, dies heute Morgen herauszufinden, haben mich mehr als eine Stunde gekostet 😢).

@pleunv @xogeny Können Sie uns einen kleinen Repro-Fall zur Verfügung stellen, damit wir dieses Problem ein für alle Mal beheben können? Es ist sehr schwer, dies für uns zu verfolgen :(

@BYK Wenn ich nichts vermisse, würde ein solcher Testfall notwendigerweise ein privates Repo erfordern. Um yarn erfolgreich zu testen, müssten wir ein privates Zugriffstoken freigeben. Das scheint bestenfalls umständlich.

Es scheint, als wäre der beste Ansatz für das Yarn-Projekt selbst, einige private Repositorys (über ein billiges, minimales Organisationskonto) einzurichten, damit Sie diese Tests durchführen können, indem Sie ein Zugriffstoken über eine Umgebungsvariable über CircleCI oder Ihren lokalen Entwickler bereitstellen. Testumgebung. Auf diese Weise wäre es Ihr Token und Sie müssten es mit niemandem teilen.

Aber ich bin offen für andere Vorschläge. Ich weiß nur nicht genau, wie ich Dinge organisieren soll.

Ja, der private Bereich macht es etwas schwierig, Ihnen einen Repro zur Verfügung zu stellen. In beiden Fällen hatten wir dies auf unserem CI mit jedem Paket mit privatem Gültigkeitsbereich auf dem Standard-Docker-Container nodeJS.

@BYK Ich kann eine Testversion eines Bintray npm-Repositorys mit einem zugehörigen Repro-Repo einrichten und Ihnen den Zugriffsschlüssel per E-Mail senden, wenn dies hilfreich ist.

@SpainTrain Vielen Dank, Einstellung

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

an die Spitze von .npmrc es mit yarn v1.3.2 behoben

In meiner Situation verschwand das Problem, als ich yarn.lock aktualisierte, um private Pakete von npmjs.com anstelle von yarnpkg.com wie folgt aufzulösen -

"@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.*"

Keine dieser Lösungen hat bei mir funktioniert. Wir verwenden nicht einmal ein privates Paket, sondern nur eine öffentliche Abzweigung eines öffentlichen Pakets. Yarn.lock wurde geändert, um auf npmjs.com zu verweisen. Vor dem Schritt der Garninstallation wurde die Garnregistrierungseinstellung verwendet.

CircleCI erhält aus irgendeinem Grund nur zeitweise 404-Werte für "Codeload" -Github-URLs während des Garninstallationsschritts.

Ich kann auch bestätigen, dass nach dem Ausführen von yarn config set registry https://registry.npmjs.org wie von @xogeny vorgeschlagen, yarn add @org/priv-module nicht mehr 404s ist und das Paket korrekt installiert wird.

Hier ist jedoch der interessante Teil: Ich bin zurück zur ursprünglichen Registrierung gewechselt ( yarn config set registry https://registry.yarnpkg.com ), habe rm -rf *; yarn cache clean und yarn add @org/priv-module erneut ausgeführt und konnte den 404 nicht mehr reproduzieren, dh er wurde installiert korrekt. Ich bin mir ziemlich sicher, dass ich hier nicht verrückt bin - yarn add @org/priv-module hat beim ersten Mal 404 gemacht.

Wie genau funktioniert registry.yarnpkg.com Proxy registry.npmjs.org ? Sie haben das Gefühl, dass nach einem erfolgreichen Abruf ein Cache gefüllt wurde?

Ich bin auf v1.3.4 unter macOS 10.13.2 und .npmrc ist einfach nur //registry.npmjs.org/:_authToken={auth token} ol

Gleiches Problem hier. Hier ist ein Protokoll von 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.

Lustige Sache: Vor Ort funktioniert alles einwandfrei.

Nur zur Vervollständigung hier ein paar fehlerhafte Circleci-Builds, und das 404-Paket ist nicht immer dasselbe:

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

Ich habe mein Problem (hoffentlich) behoben, indem ich dieser Anweisung gefolgt bin und einen Offline-Spiegel erstellt habe, aber dies ist sicherlich nicht der Weg, den jeder gehen kann.

Beeindruckend. Es stellte sich heraus, dass mein Problem nicht Teil dieses Problems war, sondern eher Teil einer globaleren Sache: https://github.com/floatdrop/pinkie/issues/18

Scheiße, jetzt haben wir auch dieses Problem bekommen. Privates Paket. Zufällige Reproduktion - funktioniert manchmal (mit einigen Versionen), manchmal nicht.

Diesen Fehler in unserem Projekt sehen. Es ist bizarr, da ich keine 404 bekomme, wenn ich die URL manuell drücke:

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)

Wir haben alle Fehler wie diese behoben, indem wir unsere URLs ein wenig geändert haben. Vermeiden Sie tar / gz und verwenden Sie tarball, dh:

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

Wenn Ihr Paket privat auf npmjs.org gehostet wird, hat das Entfernen der Zeile <strong i="5">@scope</strong>:registry=https://registry.npmjs.org/ aus .npmrc für uns funktioniert - vermutlich aufgrund von Problemen mit yarnpkg als CDN für npmjs.org

Ich stelle das heute aus
error An unexpected error occurred: “https://registry.yarnpkg.com/@types/webpack/-/webpack-3.8.10.tgz: Request failed \“404 Not Found\“”.
Kein privates Repo :(

+1 für mich. Begann es auch heute zu erleben. Versuchen Sie, das Webpack auf unserem CI zu installieren.

Gleich hier lol. Versucht spätestens

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

Es wird hier diskutiert https://github.com/yarnpkg/yarn/issues/5530

In meinem Fall hatte ich ein lokales .npmrc , das eine private Registrierung für einen bestimmten Bereich definierte. Alles, was ich hinzufügen musste, war registry=https://registry.npmjs.org/ oben in der Datei. Ergebend:

# .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

Bei der Arbeit mit CircleCI wurden auch 404 mit Garn installiert.

Garnschloss entfernen

Das hat bei mir funktioniert. Beim weiteren Graben stellte sich heraus, dass das Garnschloss schlechte URLs enthielt.

Die Garnsperre verwendete registry.yarnpkg.com, das auf CircleCI verwendet wurde (keine Ahnung, warum es lokal funktionierte).

Die resultierende Konfiguration, die den Trick ausgeführt hat:

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

Vielen Dank, auch ich habe dieses Problem durch Löschen von yarn.lock behoben.

Für mich war der fehlgeschlagene Befehl yarn add gatsby-plugin-react-helmet react-helmet .

Ich konnte ein yarn upgrade ausführen (aus Neugier ausprobiert), und dann funktionierte der obige Befehl. Ich bin mir nicht sicher, warum das so ist, aber ich wäre dankbar, wenn jemand eine Erklärung hätte.

Möglicherweise wird npm benötigt, da keine Abhängigkeit von Garn-Repositories verfügbar ist

habe das gleiche Problem mit Garn + CI + Material

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.