Yarn: Die Installation des git + ssh-Pakets scheint nicht zu funktionieren

Erstellt am 5. Okt. 2016  ·  103Kommentare  ·  Quelle: yarnpkg/yarn

Hinweis des OP: Wenn Sie auch dieses GENAUE Problem haben, stimmen Sie dies bitte OHNE Kommentar ab.


Möchten Sie eine Funktion anfordern oder einen Fehler melden?

Fehler

Wie ist das aktuelle Verhalten?

yarn install v0.14.0
info No lockfile found.
[1/4] 🔍  Resolving packages...
error Couldn't find package "<package>" on the "npm" registry.

Wenn das aktuelle Verhalten ein Fehler ist, geben Sie bitte die Schritte zur Reproduktion an.

"devDependencies": {
    "license-builder": "git+ssh://[email protected]/fishrock123/<package>.git",
}

Was ist das erwartete Verhalten?

typische Installation

Bitte geben Sie Ihre node.js, Garn und Betriebssystemversion an.

Node.js: v6.6.1-pre
Garn: v0.14.0 ( master )
Betriebssystem: OSX 10.10.5

cat-bug

Hilfreichster Kommentar

Für den Kontext aus den NPM-Dokumenten :

npm install <git remote url>:

Installiert das Paket vom gehosteten Git-Anbieter und klont es mit Git. Zuerst wird es über https (git mit github) versucht und wenn dies fehlschlägt, über ssh.

<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish>]

<protocol> ist eines von git , git+ssh , git+http , git+https oder git+file . Wenn kein <commit-ish> angegeben ist, wird master verwendet.

Es sollte auch beachtet werden, dass <commit-ish> eine ziemlich breite Palette von auflösbaren Werten ist.

Ein commit Objekt oder ein Objekt, das rekursiv auf ein commit Objekt dereferenziert werden kann. Das Folgende sind alle Festschreibungen: ein commit Objekt, ein tag Objekt, das auf ein commit Objekt zeigt, ein tag Objekt, das auf ein tag Objekt, das auf ein commit Objekt usw. zeigt.

Hinweis: Diese Git-Remote-URL-Installationen sollten auch sichergestellt werden, dass sie sowohl auf öffentlichen als auch auf privaten Git-Serverinstanzen mit SSH-Schlüsseln für die Serverauthentifizierung funktionieren, nicht nur mit GitHub / GitLab / etc. Sie können sich ein Szenario vorstellen, in dem ein Unternehmen einen lokalen Git-Server intern für alle intern verwalteten Abhängigkeiten verwendet (oder sogar private GitHub-Repos, auf die über SSH zugegriffen wird). Derzeit ist yarn nicht für diese relativ häufigen Anwendungsfälle eingerichtet.

Der einfachste Weg, einen Repro-Fall einzurichten, besteht darin, zu versuchen, ein Paket aus einem privaten GitHub-Repository mit Yarn zu installieren.

Alle 103 Kommentare

Haben Sie einen Repro, den ich wörtlich verwenden kann? Probleme beim Reproduzieren.

Nein Entschuldigung.

Es war allerdings nicht von meinem persönlichen Github. Es ist "git+ssh://[email protected]/<org>/<package>.git"

Das Repo ist privat und ich habe Lese- / Schreibzugriff. (Dies greift über einen SSH-Schlüssel zu, der in meinem Github-Konto registriert ist.)

Gibt es zusätzliche Protokollausgaben, die ich irgendwie für Sie bekommen kann?

Ich werde erwähnen, dass dies mit mehr als einer solchen Kennung geschieht.

Minimale Reproduktion:

{
  "name": "x",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "devDependencies": {
      "eslint-config-radweb": "git+https://[email protected]/radweb/eslint-config-radweb.git"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Das Paket befindet sich nicht in der Registrierung, wenn dies einen Unterschied macht.

Dies ist auch ein Fehler bei der Angabe eines Git-Tags (was npm zulässt).

Beispielausschnitt:

...
  "react-quill": "git+https://[email protected]/alexkrolick/react-quill.git#v2.0.1",
...

Ich bekomme auch diese # 621

Nur das Hinzufügen für den Fall, dass die Subtilität anders ist / erfordert eine zusätzliche Lösung für den @ BBB- Fall des Git-Tags:

Ich versuche einen _spezifischen Commit-Hash_ mit git + ssh zu installieren. Der NPM-Standardclient unterstützt dies.

Sieht aus wie # 573, # 633 und # 639 verwandt sind

Für den Kontext aus den NPM-Dokumenten :

npm install <git remote url>:

Installiert das Paket vom gehosteten Git-Anbieter und klont es mit Git. Zuerst wird es über https (git mit github) versucht und wenn dies fehlschlägt, über ssh.

<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish>]

<protocol> ist eines von git , git+ssh , git+http , git+https oder git+file . Wenn kein <commit-ish> angegeben ist, wird master verwendet.

Es sollte auch beachtet werden, dass <commit-ish> eine ziemlich breite Palette von auflösbaren Werten ist.

Ein commit Objekt oder ein Objekt, das rekursiv auf ein commit Objekt dereferenziert werden kann. Das Folgende sind alle Festschreibungen: ein commit Objekt, ein tag Objekt, das auf ein commit Objekt zeigt, ein tag Objekt, das auf ein tag Objekt, das auf ein commit Objekt usw. zeigt.

Hinweis: Diese Git-Remote-URL-Installationen sollten auch sichergestellt werden, dass sie sowohl auf öffentlichen als auch auf privaten Git-Serverinstanzen mit SSH-Schlüsseln für die Serverauthentifizierung funktionieren, nicht nur mit GitHub / GitLab / etc. Sie können sich ein Szenario vorstellen, in dem ein Unternehmen einen lokalen Git-Server intern für alle intern verwalteten Abhängigkeiten verwendet (oder sogar private GitHub-Repos, auf die über SSH zugegriffen wird). Derzeit ist yarn nicht für diese relativ häufigen Anwendungsfälle eingerichtet.

Der einfachste Weg, einen Repro-Fall einzurichten, besteht darin, zu versuchen, ein Paket aus einem privaten GitHub-Repository mit Yarn zu installieren.

Wenn Sie die folgende Quellzeichenfolge angeben:

"devDependencies": {
    "license-builder": "ssh://github.com/<user>/<package>",
}

Anschließend wird versucht, das angegebene Repository über SSH zu klonen, dies schlägt jedoch mit "Berechtigung verweigert (öffentlicher Schlüssel)" fehl, da GitHub erwartet, dass sich Clients als Benutzer git anmelden. In diesem Fall wurde standardmäßig der Benutzer des lokalen Kontos verwendet .

Wenn Sie git@ angeben, um git zu zwingen, sich als git bei GitHub anzumelden, schlägt dies mit den üblichen Schritten fehl:

error Couldn't find any versions for <package> that matches ssh://[email protected]/<user>/<package>.

Es funktioniert also fast, unterstützt jedoch nicht die Angabe des Benutzernamens. Wenn Ihr lokaler Kontonutzer zufällig git , ist dies tatsächlich erfolgreich.

Wenn Sie Ihrer ~/.ssh/config -Datei Folgendes hinzufügen:

Host github.com
        User git

Sie können alle Anmeldungen bei github.com über SSH zwingen, standardmäßig den Benutzer git Dadurch kann Garn aus privaten Repositorys geklont werden, wenn das Quellformat ssh://github.com/<user>/<package> verwendet wird.

Dies ist ein starkes No-Go für uns. Die Verwendung von git-referenzierten Repos (die auf unsere lokale gitlab EE-Instanz verweisen) ist ein wichtiger Bestandteil unseres Workflows: cry:
Es ist auch sehr nützlich, um Pakete "vor dem Zusammenführen und npm veröffentlichen" (z. B. http-proxy ...) zu verzweigen und darauf zu verweisen.

@milosivanovic

Wenn Sie Ihrer ~ / .ssh / config-Datei Folgendes hinzufügen:

Aber meine Konfiguration hat bereits meine SSH-Authentifizierungsdaten für Github, damit ich auf die privaten Repos zugreifen kann. Diese Problemumgehung funktioniert nur für öffentliche Repos, oder?

@milosivanovic @ntucker tatsächlich funktionierte dies in meinem speziellen Fall; Ich hatte zu Beginn keine SSH-Konfigurationsdatei.

@kblcuk ah, nun, @milosivanovic ging zu anderen Problemen über und behauptete, seine

@ntucker Die angegebene Host github.com -Eintrag in ~/.ssh/config , fügen Sie diesem Eintrag User git , und das Garn kann klonen, wenn Sie eine Quellzeichenfolge wie ssh://github.com/<user>/<package> angeben

@milosivanovic Woher kennt Github meinen Benutzernamen, um dann SSH-

@ntucker Bei der Kommunikation über SSH erwartet GitHub, dass Sie sich als Benutzer "git" bei ihren Servern anmelden. Wenn Sie versuchen, sich mit Ihrem üblichen GitHub-Benutzernamen anzumelden, schlägt die Authentifizierung fehl. GitHub über SSH unterscheidet Sie anhand Ihres öffentlichen Schlüssels und nicht anhand Ihres Benutzernamens. Referenz: https://help.github.com/articles/testing-your-ssh-connection/

Ich dachte nur zu erwähnen, weil viele diese Funktion wahrscheinlich nicht kennen. Für GitHub können Sie sich auch auf die Tarball-URL verlassen, die mit yarn funktioniert. Wird auch schneller installiert.

https://github.com/user/repo/tarball/branch

@milosivanovic Leider Problemumgehung für unsere internen URLs im Format nicht:
git+ssh://[email protected]:team-name/repo.git

Wenn Sie das anfängliche Repo in das Format ssh://source.com/team-name/repo.git ändern ...

... dann funktioniert es für die erste ... aber dann natürlich alle anderen internen Abhängigkeiten, auf die die erste interne Abhängigkeit hinweist, um sie zu brechen, da sie alle in diesem Format vorliegen.

Ohne alle URLs aller unserer Repos und Abhängigkeiten auf das Workaround-Format durchzugehen und zu ändern (und dann damit umgehen zu müssen, funktioniert es normalerweise nicht mit npm), sind wir auch hier ein bisschen blockiert.

Wie @ 131 hervorhob, ist dies eine wichtige Methode, mit der Teams npm intern verwenden (was mir bekannt ist).

Sieht aber trotzdem gut aus!

@brokenalarms Das ssh://host.com/user/repo -Format ist vollständig abwärtskompatibel mit npm (solange der erwartete Benutzer in der SSH-Konfigurationsdatei angegeben ist), aber das ist trotzdem ein fairer Punkt.

Ich verstehe ... also wissen sie nur, welcher Benutzer dann auf dem SSH-Schlüssel basiert?

@ntucker ja

Ich hatte das gleiche Problem, aber die Lösung von ntucker, User Git zu ~ / .ssh / config hinzuzufügen, hat mir geholfen. Zumindest in der Entwicklungsumgebung. Ich werde jetzt versuchen, AWS EB bereitzustellen :)

Kann bestätigen, dass die Verwendung von git+ssh://[email protected]:<org>/<repo> in yarn nicht funktioniert und die Änderung in https://github.com:<org>/<repo> funktioniert, aber auf unserem CI-Server, der weiterhin _NPM _ verwendet,

Diese Problemumgehung hat mir geholfen:

  1. hat meine private Repository-URL von geändert
git+ssh://git@host/user/private-repo.git 

zu

ssh://host/user/private-repo.git
  1. User git zu ~ / .ssh / config hinzugefügt:
Host bitbucket.org
    User git

Host github.com
    User git

Hat jemand überprüft, ob Problemumgehungen mit Bitbucket funktionieren?

@ Tgarbiak - Ja, ich benutze Bitbucket.

Mit BitBucket habe ich dies zu meiner ~ / .ssh / config hinzugefügt:

Host stash.company.com
    port 7999
    User shawn

Und verwendetes Garn, um dieses Paket hinzuzufügen:

yarn add ssh://stash.company.com:7999/~user/package.git

Wenn ich npm install ausführe, funktioniert es einwandfrei, aber wenn ich yarn install ausführe, wird folgende Fehlermeldung angezeigt:

error TypeError: Cannot read property 'endsWith' of undefined
    at removeSuffix (/Users/slooker/.nvm/versions/node/v6.4.0/lib/node_modules/yarnpkg/lib/util/misc.js:42:14)
    at Function.parseRefs (/Users/slooker/.nvm/versions/node/v6.4.0/lib/node_modules/yarnpkg/lib/util/git.js:447:55)
    at /Users/slooker/.nvm/versions/node/v6.4.0/lib/node_modules/yarnpkg/lib/util/git.js:376:24
    at next (native)
    at step (/Users/slooker/.nvm/versions/node/v6.4.0/lib/node_modules/yarnpkg/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
    at /Users/slooker/.nvm/versions/node/v6.4.0/lib/node_modules/yarnpkg/node_modules/babel-runtime/helpers/asyncToGenerator.js:28:20
    at run (/Users/slooker/.nvm/versions/node/v6.4.0/lib/node_modules/yarnpkg/node_modules/core-js/library/modules/es6.promise.js:87:22)
    at /Users/slooker/.nvm/versions/node/v6.4.0/lib/node_modules/yarnpkg/node_modules/core-js/library/modules/es6.promise.js:100:28
    at flush (/Users/slooker/.nvm/versions/node/v6.4.0/lib/node_modules/yarnpkg/node_modules/core-js/library/modules/_microtask.js:18:9)
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Ja, wie bereits erwähnt, funktioniert diese Problemumgehung.

Der Punkt ist, dass sich dies in jedem unserer 50+ ändern wird
Abhängigkeiten und die Anforderung, dass jeder zukünftige Benutzer jetzt die zusätzlichen übernimmt
Schritt der Vorbereitung ihrer SSH-Konfigurationsdatei für die Arbeit mit Garn oder der
Das vorhandene npm-Setup ist leider keine Option.

Am Mittwoch, 12. Oktober 2016, 03:47 Uhr schrieb Sven Varkel [email protected] :

Diese Problemumgehung hat mir geholfen:

  1. Die URL meines privaten Repositorys wurde von git + ssh: //git@host/user/private-repo.git geändert
    zu
    ssh: //host/user/private-repo.git
  2. User git zu ~ / .ssh / config hinzugefügt:
    ``
    Host bitbucket.org
    User git

Host github.com
User git

- -
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/513#issuecomment -253180666 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AHC8CnUaBP_B_FL_AX1xL5FUrEWR-rnPks5qzLrTgaJpZM4KO4Cm
.

@diorman & jeder, der dies liest: Ich empfehle dringend, dass Sie kein Github-Token in Ihre package.json-Datei in der Quellcodeverwaltung einchecken.

@jsdnxx danke für den Hinweis. Ich bin gerade in ein großes privates Projekt gesprungen, das das Token für private Abhängigkeiten bereits auf package.json hatte. Wird Ihrem Rat folgen. Danke noch einmal

Bei Filialen scheint die Tarball-Problemumgehung von https://github.com/yarnpkg/yarn/issues/513#issuecomment -253059522 möglicherweise aufgrund von Caching nicht zu funktionieren. Ich verwende Yaska/keystone#yaska-build als zu installierenden Paketnamen und es wird ein falsches Commit verwendet. Wenn https://github.com/Yaska/keystone/tarball/yaska-build , wird immer noch das falsche Commit verwendet. npm behandelt es korrekt.

Wenn ich eine private Repo-Abhängigkeit lokal yarn link bearbeitet habe, sollte Garn nicht einmal prüfen, ob diese Abhängigkeit in der npm-Registrierung enthalten ist, aber derzeit schlägt Garn in diesem Fall ohne eine der beiden fehl In diesem Thread erwähnte Problemumgehungen.

Die vorgeschlagene ~ / .ssh / config-Konfiguration unterbricht die Paketauflösung und funktioniert daher nicht. Hoffentlich wird die PR, die dies behebt, bald zusammengeführt, andernfalls zurück zum guten alten NPM.

Problemumgehung für Gitlab verwendet dieses Format:

{
    "PROJECT": "http://gitlab.com/NAMESPACE/PROJECT/repository/archive.tar.gz?ref=BRANCH_OR_TAG"
}

Funktioniert auch mit privatem Repository. Verwenden Sie Gitlab Personal Access Token :

{
    "PROJECT": "http://gitlab.com/NAMESPACE/PROJECT/repository/archive.tar.gz?ref=BRANCH_OR_TAG&private_token=TOKEN"
}

@Webysther - wie @jsdnxx sagte:

Ich empfehle dringend, dass Sie kein Github-Token in Ihre package.json-Datei in der Quellcodeverwaltung einchecken.

Das gleiche gilt natürlich für GitLab oder andere private Token.

Private Token ist nur für Parameter gedacht, die neuere Version von Gitlab kann mehrere Zugriffstoken verwalten.
Ich würde gerne git + ssh in Garn verwenden ...

Aus Gitlab Docs:

Persönliche Zugriffstoken

Sie können für jede von Ihnen verwendete Anwendung, die Zugriff auf die GitLab-API benötigt, ein persönliches Zugriffstoken generieren.

Privates Token

Ihr privates Token wird verwendet, um ohne Authentifizierung auf Anwendungsressourcen zuzugreifen.

Ich habe mir den Code angesehen und es scheint mir, dass einmal ein Git Repo gewesen ist
erhalten, wird sein Commit-Hash nicht mehr überprüft, so dass Sie keinen Zweig verfolgen können.

Ist das eine korrekte Einschätzung, und wenn ja, gehört das in eine andere
Problem?

Am Freitag, 14. Oktober 2016, um 06:52 Uhr Webysther Nunes [email protected]
schrieb:

Private Token ist nur für param, neuere Version von Gitlab in der Lage zu verwalten
Mehrfachzugriffstoken.
Ich würde gerne git + ssh in Garn verwenden ...

Aus Gitlab Docs:
Persönliche Zugriffstoken

Sie können für jede Anwendung, die Sie verwenden, ein persönliches Zugriffstoken generieren
benötigt Zugriff auf die GitLab-API.
Privates Token

Ihr privates Token wird verwendet, um ohne auf Anwendungsressourcen zuzugreifen
Authentifizierung.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/yarnpkg/yarn/issues/513#issuecomment -253709157 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AADWlhxxjS7Kl1wt_Wm6UG1Q_7X86D7oks5qzwqYgaJpZM4KO4Cm
.

@wmertens Nein, die Version bleibt in yarn.lock gesperrt. Versuchen Sie yarn upgrade

@Webysther leider macht yarn upgrade keinen Unterschied. Es wird weiterhin das alte Commit verwendet. Ich muss beachten, dass der Zweig zwangsweise gedrückt wurde, aber ich denke nicht, dass dies wichtig ist, da Garn das Commit nachschlagen sollte, das mit dem angegebenen Tag übereinstimmt, und das installieren sollte, oder?

Ich habe eine Problemumgehung gefunden, um das Garn zu zwingen, das richtige Commit abzurufen:

Entfernen Sie das Paket aus ~/.yarn-cache und führen Sie dann yarn upgrade .

Es wird es wieder holen und die Dinge sind so, wie sie sein sollten. Ist es falsch zu erwarten, dass yarn upgrade die Commits von Git-Repos überprüft?

Ich denke, es ist richtig, dass das Garn-Upgrade nach neuen Git-Commits suchen sollte. Dies sollte jedoch eine Version pro Projekt sein, die nicht im Benutzer-Home-Verzeichnis zwischengespeichert ist. Aber das ist auch ein separater Fehler, denke ich

Unsere Projekte haben Hunderte von package.json-Einträgen des Formulars
"[name]": "[email protected]:[team]/[project].git"
Gleicher Fehler gesehen

Wird dies durch PR # 971 behoben?

@BryanCrotaz Nein, das scheint keine vollständige Lösung zu sein. Scheint auf GitHub beschränkt zu sein. Private Repos sind immer noch ein Problem (z. B. git+ssh://[email protected]:user/project.git#d6c5789 )

BEARBEITEN: Wie von @bdougherty unten ausgeführt, git+ssh://[email protected]/user/project.git#d6c5789 mit einem / anstelle von : vor dem Benutzer.

+1

Ich konnte dieses Problem umgehen, indem ich das Format der URLs von änderte

git+ssh://git<strong i="6">@host</strong>:org/repo.git

zu

git+ssh://git@host/org/repo.git

Beide Formate sind in npm gültig und der einzige Haken ist, dass alle Abhängigkeiten dieses Format verwenden müssen.

@kittens Ich denke, das ( git+ssh://git@host/org/repo.git ) funktioniert jetzt für mich?

Garn : v0.16.1
Knoten : v6.9.1


Ich habe git+ssh://git<strong i="13">@host</strong>:org/repo.git nicht ausprobiert, aber url.parse() scheint die : vollständig zu ignorieren, sodass sie möglicherweise entfernt werden müssen:

> url.parse('git+ssh://[email protected]:org/my-repo.git')
Url {
  protocol: 'git+ssh:',
  slashes: true,
  auth: 'git',
  host: 'github.com',
  port: null,
  hostname: 'github.com',
  hash: null,
  search: null,
  query: null,
  pathname: '/:org/my-repo.git',
  path: '/:org/my-repo.git',
  href: 'git+ssh://[email protected]/:org/my-repo.git' }

Vielleicht hat https://github.com/yarnpkg/yarn/pull/934 dies versehentlich behoben?

@ Fishrock123 Ich kann bestätigen, was mit Garn v0.16.0 git + ssh Paketinstallation zu funktionieren scheint.
Mit v0.13.0 schlug es konsistent mit error Couldn't find package "<package>" on the "npm" registry. für git + ssh-Pakete fehl.

@ Fishrock123 Bestätigt. Auch hier funktioniert es jetzt.

Ja, # 934 sollte dies beheben :)

Das folgende Format funktioniert jedoch nicht: git+ssh://git<strong i="6">@host</strong>:org/repo.git (mit einem : -Trennzeichen)

Gibt es Informationen darüber, wann die Unterstützung für : Separatoren kommen könnte?

Ich habe an etwas gearbeitet, aber noch keine Gelegenheit gehabt, einige Randfälle zu lösen. Ich werde versuchen, es nächste Woche zu schaffen, wenn mich niemand schlägt.

Nun, ich habe immer noch ein Problem damit, aber wahrscheinlich ein bisschen anders. Ich kann ein einzelnes Paket mit yarn add git+ssh://[email protected]/group/foo.git#0.0.4 installieren und es funktioniert sehr gut. Dann möchte ich ein weiteres für dasselbe Projekt installieren yarn add git+ssh://[email protected]/group/bar.git und plötzlich bekomme ich Couldn't find package "group-foo" on the "npm" registry.

Ich benutze Version 0.16. Soll ich damit lieber ein neues Problem erstellen?

Bearbeiten: Vielleicht möchten Sie hinzufügen, dass yarn.lock Ordnung aussieht ...

"git+ssh://[email protected]/group/foo.git#0.0.4":
  name group-foo
  version "0.0.4"
  resolved "git+ssh://[email protected]/group/foo.git#6e25bb42e1725b260d4f1c95582c18aea73e5f5c"

Edit2: Könnte tatsächlich ein Problem in package.json sein, es sieht nach der ersten Installation so aus. Offensichtlich hat es das Protokoll gelöscht, während es in yarn.lock beibehalten wurde. Ich denke, es kann es einfach nicht finden, also sieht es stattdessen in npm aus.

"dependencies": {
  "group-foo": "gitlab.com/group/foo.git#0.0.4"
}

+100

Das Aktualisieren auf v0.16.1 und die Verwendung der Syntax git+ssh://git@host/org/repo.git das Problem für mich behoben (Hinweis: würde mit der Syntax git+ssh://git<strong i="6">@host</strong>:org/repo.git immer noch nicht funktionieren)

Der Punkt ist sicherlich, vorhandene package.json-Dateien zu unterstützen, da sonst die Migration schwierig ist und eine doppelte Ausführung zum Testen unmöglich ist

Mit Garn 0.16.1 ich ein privates Repository mit der Syntax git + ssh verwenden. Außerdem wurde der Benutzer git @ korrekt verwendet.

@fermuch Und kannst du zB laufen. yarn ls nach einer solchen Installation? Wie sieht dein package.json aus, ist die URL zum privaten Repo gleich oder irgendwie geändert?

@FredyC meine Ausgabe von yarn add :

yarn add git+ssh://[email protected]/foobar/my-private-package.git
yarn add v0.16.1
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
warning Unmet peer dependency "whatwg-fetch@^1.0.0".
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 1 new dependency
└─ [email protected]

Dies wurde ausgeführt, nachdem my-private-package aus node_modules gelöscht wurde.
Nach dem yarn add kann ich die Dateien in node_modules korrekt sehen.

Garn ls Ausgänge:

error Couldn't find any versions for my-private-package that matches github.com/foobar/my-private-package.git. Possible versions: 0.1.4

Ich bin nicht sicher, warum es 0.1.4 da das Paket nicht in der npm-Registrierung vorhanden ist und das Paket des Githubs die Version 2.1.3 .

BEARBEITEN

Erwähnenswert ist auch, dass dies zu meinem yarn.lock hinzugefügt wurde:

"git+ssh://[email protected]/foobar/my-private-package.git":
  name my-private-package
  version "2.1.3"
  resolved "git+ssh://[email protected]/foobar/my-private-package.git#99186dc139e13a1420e56288efd02fd0b3158aa7"

@fermuch Ja, ich habe genau das gleiche Problem dort. Ich bin mir fast sicher, dass wenn Sie jetzt versuchen, ein anderes Paket hinzuzufügen (sogar eines von npm), es ebenfalls fehlschlägt. Ich habe bereits ein separates Problem für dieses ... # 1312 erstellt

Ich habe das gleiche Problem hier, aber mit der öffentlichen URL, nicht über ssh.

  "devDependencies": {
    "code": "2.x.x",
    "hapi": "10.x.x",
    "lab": "10.x.x",
    "k7": "[email protected]:thebergamo/k7.git#v1.5"
  },

Hallo zusammen,

Ich habe festgestellt, dass das Problem auch mit Ihrer Knotenversion zusammenhängt.

Ich verwende das Format "git + ssh: //[email protected]//..git #". Ich entwickle unter OSX und CentOS 7. Ich habe festgestellt, dass mit den neuesten Versionen von Knoten 4 (v4.6.1) und Knoten 6 (v6.9.1) Garn ohne Probleme mit diesem Format funktioniert. Mit einer älteren Version von Knoten 4 (v4.4.5) funktioniert unter OSX, jedoch nicht unter CentOS 7. Insbesondere wenn Garn versucht, das Repo herunterzuladen, bleibt es für immer hängen. Wenn das gleiche Problem auftritt, stellen Sie sicher, dass Sie die neueste Version von Knoten 4 oder 6 ausführen.

In Bezug auf kcormier habe ich sowohl den Knoten 4.6.1 als auch den Knoten 6.9.1 ausprobiert, und keiner von beiden behebt das Problem, dass Garn bestimmte markierte Versionen eines Repos über SSH nicht finden kann.

Das fehlgeschlagene Format ist:

git+ssh://[email protected]:<username>/<project>.git#<tag>

Es wird immer noch der Fehler angezeigt, dass keine Version gefunden werden kann, die dem Tag entspricht (funktioniert gut mit npm).

Ich finde, es funktioniert gut, wenn ich den Doppelpunkt nach der Domain in einen Schrägstrich ändere. Verrückt oder?

@alanhogan Ich habe auch bemerkt, dass es gut funktioniert, wenn wir den Doppelpunkt nach der Domäne in einen Schrägstrich ändern, aber wenn das Paket andere git + ssh-Abhängigkeiten hat, müssen Sie ihn in der package.json der zu installierenden Bibliothek / des zu installierenden Pakets ändern . Ein weiteres Problem besteht darin, dass selbst wenn Sie den Doppelpunkt in einen Schrägstrich ändern, ein Fehler ausgelöst wird, wenn Sie versuchen, auf ein bestimmtes Commit oder einen bestimmten Zweig zu verweisen.

Ich hatte selbst Erfolg mit Bezug auf Zweige und Tags. Ich habe Knoten 6.9.1 verwendet

Aber ja, das rekursive Problem ist real, wenn auch nicht schlecht, da theoretisch nur unsere eigenen privaten Module betroffen sind.

@ Alanhogan Ja, ich

Das obige Update scheint in meinem Fall nicht zu funktionieren. Ich habe ein offizielles Npm-Paket in meinem Repo gegabelt, und wenn ich die URL meines Repos gebe, auch mit einem / anstelle von :, löst Garn das offizielle Repo auf. (offiziell: https://github.com/TheLarkInn/angular2-template-loader, meins: https://github.com/Krisa/angular2-template-loader). Ich konnte keine Problemumgehung finden (neben der Verwendung von Npm vorerst).

Das Wechseln von einer versionierten Abhängigkeit zu einer Tarball-Abhängigkeit erfordert ein yarn cache clean bevor der Tarball tatsächlich als neues node_module (Node v6 LTS und Garn v0.16.1) entpackt wird.

Eine Armee von Entwicklern hat darüber abgestimmt. Gibt es eine Möglichkeit, wie wir helfen können?

@ f-sign arbeitet in unserem Team daran. Möchtest du Hilfe von einer Armee, Flávio?

Ein wesentlicher Teil dieses Problems scheint die Inkonsistenz von package.json und yarn.lock zu sein, wie von @FredyC beschrieben : Die package.json enthält nicht das Präfix git+ssh://git@ , das während der Installation in yarn.lock beibehalten wird . Ich dachte, dass Garn es vorzieht, die Datei yarn.lock zu betrachten, anstatt die Auflösungsinformationen aus package.json abzurufen

Nachdem Sie die Datei package.json von Hand bearbeitet und das Präfix festgelegt hatten, funktionierte alles einwandfrei.

@maybeec Dieses Problem ist in der Hauptniederlassung bereits gelöst ... https://github.com/yarnpkg/yarn/issues/1312#issuecomment -258230803

Gut gemacht, ich freue mich auf die nächste Veröffentlichung. Ich denke, es wird viele Probleme beheben.

Ja, ich bin völlig verblüfft, was es mit Neuerscheinungen auf sich hat. Dieser ist jetzt wie ein Monat? Ich denke, es ist eine strenge Facebook-Richtlinie oder was ... 😢

1784 fordert eine neue Version. Bitte hinterlassen Sie einfach eine Daumen-hoch-Reaktion!

Mein Problem beschreibt ein Problem, das ähnlich ist, obwohl es nicht dasselbe ist. Ich habe den Code ein wenig durchgesehen und diesen interessanten Teil gefunden , der tatsächlich auf jeder Git-URL verwendet wird:

static cleanUrl(url): string {
    return url.replace(/^git\+/, '');
}

Soooo ... Kann mir jemand sagen, was der Grund für das Entfernen von _git + _ für jede an Garn übergebene

1816 kann dies beheben - werfen Sie einen Blick auf die Codeänderungen - es behebt sicherlich das Problem mit dem Doppelpunkt nach der Domäne

Das Problem scheint bei Garn v0.17.0 behoben zu sein. Ich konnte eines meiner privaten Github-Repositorys für eine bestimmte Version herunterladen.

Ist dieses Problem behoben? Ich versuche, mein Projekt von npm auf Garn zu migrieren, habe aber immer noch Probleme mit

@viswanathamsantosh Scheint auf meiner Seite zu arbeiten

image

Es sieht so aus, als ob dies hier behoben ist. https://github.com/yarnpkg/yarn/pull/971 ! Das Ersetzen von Doppelpunkt (:) durch Schrägstrich (/) hat tatsächlich funktioniert. : ')

Das Ersetzen des Doppelpunkts durch einen Schrägstrich funktioniert in meinem Fall nicht :( _git + ssh: //git@private..._ wird immer noch auf _ ssh: //git@private..._ reduziert.

Ja, ich habe auch dieses Problem immer noch, selbst mit Version 0.17.2 von Yarn. Der git+ Teil wird entfernt und ich bekomme:

Permission denied (publickey).
fatal: Could not read from remote repository.

Angesichts der Tatsache, dass es für einige Leute funktioniert, bin ich verwirrt. Irgendeine Idee, was wir falsch machen?

Platziere dies in ~ / .ssh / config

Host github.com
        User git

Ja! Das hat es für mich behoben. Vielen Dank.

Es wäre jedoch schön, wenn cleanUrl nicht ausgeführt würde, sodass wir dies stattdessen direkt in der URL haben könnten. Das Ändern einer Konfigurationsdatei erfordert eine Devops-Änderung, bei der die Versionskontrolle sie sonst handhaben könnte. Nicht sicher, was der Denkprozess dahinter war ...?

Selbes Problem hier. URLs von privaten Repositorys funktionieren nicht mehr wie zuvor (npm).

git + ssh: //[email protected] : ORG / repo.git sollte so funktionieren, wie es benötigt wird, um während der Migrationsphase mit npm kompatibel zu sein ...

@DominicBoettger Sobald Sie User git zu Ihrem ~/.ssh/config hinzugefügt haben, möchten Sie diesen Doppelpunkt auch in einen Schrägstrich ändern. Nach meiner heutigen Erfahrung spielt Yarn noch nicht gut mit dem Doppelpunkt.

git+ssh://github.com/ORG/repo.git

Abhängigkeiten des Formulars

git+ssh://[email protected]:myuser/repo.git#v1.0.0",

arbeite nicht für mich mit dem neuesten Garn 017.2 . Der Fehler ist:

ssh: Could not resolve hostname bitbucket.org:myuser: Name or service not known

Ich habe die Problemumgehungen noch nicht getestet, hoffe jedoch, dass Garn letztendlich die gleiche Syntax wie NPM unterstützt. Sollte dies ein neues Problem sein oder gilt dies immer noch für dieses Problem?

@sarus PR # 1816 wird dies beheben

Bitte führen Sie PR # 1816 zusammen und veröffentlichen Sie eine neue Version 👍

Verschmelzen? Jemand? NPM treibt mich Nüsse an !! Bitte zusammenführen und freigeben :(

Dieses Problem bleibt in Version 0.18.0.

Das Aufrufen von yarn install in einem sauberen Projekt ohne node_modules und die Datei yarn.lock funktioniert. Wenn Sie es direkt danach erneut aufrufen, wird der Fehler "Hostname konnte nicht behoben werden" angezeigt.

Ich habe festgestellt, dass das Entfernen der Datei yarn.lock funktioniert. Daher gehe ich davon aus, dass entweder etwas in der Sperrdatei nicht stimmt oder wie das Garn beim Lesen aus einer Sperrdatei geklont wird.

Hoffe das hilft!

Dieses Problem ist genau das, was viele Entwickler davon abhält, Garn zu verwenden.
Wir müssen dieses Problem ernst nehmen

@regou stimme vollkommen zu Mann ... Dies ist der einzige Grund, warum ich Garn nicht verwenden kann ...

Leute, anstatt ständig zu jammern, dass niemand daran arbeitet, schauen Sie sich einfach die PR # 1816 an und Sie werden sehen, dass sie versuchen, sie zusammenzuführen ...

Bitte alle, wir haben eine Lösung dafür in # 1816, für die Flavio und ich ungefähr zehn Tage verbracht haben.

Je nachdem, wo die Tests ausgeführt werden, schlägt jedoch ein anderer Testsatz fehl.

Führen Sie die Tests auf Ihrem Computer aus und berichten Sie auf # 1816, welche Ergebnisse Sie erhalten haben und wie Ihr Betriebssystem und Ihre Knotenversion aussehen

Vielen Dank an @FredyC & @BryanCrotaz für den Hinweis auf # 1816. Ich sperre diesen Thread vorerst.

Behoben über # 2384

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen