Yarn: L'installation du package git + ssh ne semble pas fonctionner

Créé le 5 oct. 2016  ·  103Commentaires  ·  Source: yarnpkg/yarn

Remarque de l'OP: si vous rencontrez également ce problème EXACT, veuillez le voter SANS commenter.


Voulez-vous demander une _fonctionnalité_ ou signaler un _bug_?

punaise

Quel est le comportement actuel?

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

Si le comportement actuel est un bogue, veuillez fournir les étapes à reproduire.

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

Quel est le comportement attendu?

installation typique

Veuillez mentionner votre node.js, votre fil et la version de votre système d'exploitation.

Node.js: v6.6.1-pre
Fil: v0.14.0 ( master )
Système d'exploitation: OSX 10.10.5

cat-bug

Commentaire le plus utile

Pour le contexte, à partir de la documentation de

npm install <git remote url>:

Installe le package à partir du fournisseur git hébergé, en le clonant avec git. Il essaie d'abord via https (git avec github) et si cela échoue, via ssh.

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

<protocol> est l'un des git , git+ssh , git+http , git+https ou git+file . Si aucun <commit-ish> n'est spécifié, alors master est utilisé.

Il convient également de noter que <commit-ish> est un assez large éventail de valeurs résolubles.

Un objet commit ou un objet qui peut être déréférencé récursivement en un objet commit . Ce qui suit sont tous des commit-ishes: un objet commit , un objet tag qui pointe vers un objet commit , un objet tag qui pointe vers un objet tag objet qui pointe vers un objet commit , etc.

Remarque: Ces installations d'URL distantes git doivent également être assurées de fonctionner sur les instances de serveur git publiques et privées en utilisant des clés SSH pour l'authentification du serveur, pas seulement GitHub / GitLab / etc. Vous pouvez imaginer un scénario dans lequel une entreprise utilise un serveur git local en interne pour toutes ses dépendances gérées en interne (ou même des dépôts GitHub privés accessibles via SSH). À l'heure actuelle, yarn n'est pas configuré pour s'adapter à ces cas d'utilisation _ relativement courants_.

Le moyen le plus simple de configurer un cas de repro serait d'essayer d'installer un package à partir d'un référentiel GitHub privé à l'aide de Yarn.

Tous les 103 commentaires

Avez-vous un repro que je peux utiliser textuellement? Avoir du mal à reproduire cela.

Non désolé.

Ce n'était pas vraiment de mon github personnel. C'est "git+ssh://[email protected]/<org>/<package>.git"

Le dépôt est privé et j'ai un accès en lecture / écriture. (Cela y accède via une clé SSH enregistrée sur mon compte github)

Y a-t-il une sortie de journal supplémentaire que je peux obtenir pour vous?

Je mentionnerai que cela se produit avec plus d'un identifiant.

Repro minimum:

{
  "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"
}

Le package n'est pas sur le registre, si cela fait une différence.

Cela entraîne également des erreurs lors de la spécification d'une balise git (ce que npm autorise).

Exemple d'extrait:

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

Je reçois aussi ce # 621

Il suffit d'ajouter si la subtilité est différente / nécessite une solution supplémentaire au cas @BBB de la balise git:

J'essaye d'installer un hash de commit spécifique avec git + ssh. Le client par défaut NPM prend en charge cela.

On dirait que # 573, # 633 et # 639 sont liés

Pour le contexte, à partir de la documentation de

npm install <git remote url>:

Installe le package à partir du fournisseur git hébergé, en le clonant avec git. Il essaie d'abord via https (git avec github) et si cela échoue, via ssh.

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

<protocol> est l'un des git , git+ssh , git+http , git+https ou git+file . Si aucun <commit-ish> n'est spécifié, alors master est utilisé.

Il convient également de noter que <commit-ish> est un assez large éventail de valeurs résolubles.

Un objet commit ou un objet qui peut être déréférencé récursivement en un objet commit . Ce qui suit sont tous des commit-ishes: un objet commit , un objet tag qui pointe vers un objet commit , un objet tag qui pointe vers un objet tag objet qui pointe vers un objet commit , etc.

Remarque: Ces installations d'URL distantes git doivent également être assurées de fonctionner sur les instances de serveur git publiques et privées en utilisant des clés SSH pour l'authentification du serveur, pas seulement GitHub / GitLab / etc. Vous pouvez imaginer un scénario dans lequel une entreprise utilise un serveur git local en interne pour toutes ses dépendances gérées en interne (ou même des dépôts GitHub privés accessibles via SSH). À l'heure actuelle, yarn n'est pas configuré pour s'adapter à ces cas d'utilisation _ relativement courants_.

Le moyen le plus simple de configurer un cas de repro serait d'essayer d'installer un package à partir d'un référentiel GitHub privé à l'aide de Yarn.

Si vous spécifiez la chaîne source suivante:

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

il ne tente de cloner le dépôt indiqué sur SSH, mais échoue avec « Permission refusée (publickey) » parce GitHub attend les clients de connexion comme git utilisateur, et dans ce cas , l'utilisateur du compte local a été utilisé par défaut .

Lorsque vous spécifiez git@ pour forcer git à se connecter en tant que git à GitHub, cela échoue avec l'habituel:

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

Donc, cela fonctionne presque, mais ne prend pas en charge la spécification du nom d'utilisateur. Si l'utilisateur de votre compte local s'appelait git , cela réussirait.

Si vous ajoutez ce qui suit à votre fichier ~/.ssh/config :

Host github.com
        User git

vous pouvez forcer toutes les connexions à github.com via SSH à utiliser l'utilisateur git par défaut, ce qui rend yarn capable de cloner à partir de référentiels privés en utilisant le format source ssh://github.com/<user>/<package> .

C'est une forte interdiction pour nous, l'utilisation de dépôts référencés git (pointant notre instance locale gitlab EE) est une partie importante de notre flux de travail: cry:
Il est également très utile pour bifurquer et pointer vers les packages "before merge and npm publish" (par exemple, http-proxy ...)

@milosivanovic

Si vous ajoutez ce qui suit à votre fichier ~ / .ssh / config:

Mais ma configuration a déjà mes informations d'authentification ssh pour github afin que je puisse accéder aux dépôts privés. Cette solution de contournement ne fonctionne que pour les dépôts publics, non?

@milosivanovic @ntucker en fait cela a fonctionné dans mon cas particulier; Je n'avais aucun fichier de configuration ssh pour commencer.

@kblcuk ah, eh bien @milosivanovic traitait d'autres problèmes et affirmait que sa solution de contournement fonctionnait pour ces cas, alors j'ai pensé que c'était le problème pour les problèmes généraux avec les URL git.

@ntucker, la solution de contournement indiquée concerne les référentiels privés. Si vous avez déjà une entrée Host github.com dans ~/.ssh/config , ajoutez User git à cette entrée et yarn pourra cloner lorsque vous spécifiez une chaîne source telle que ssh://github.com/<user>/<package> , c'est-à-dire sans "git +" et sans aucun utilisateur spécifié.

@milosivanovic Comment github connaît-il mon nom d'utilisateur pour faire l'authentification ssh alors?

@ntucker lors de la communication via SSH, GitHub s'attend à ce que vous vous https://help.github.com/articles/testing-your-ssh-connection/

Je pensais juste à le mentionner car beaucoup ne sont probablement pas conscients de cette fonctionnalité. Pour GitHub, vous pouvez également compter sur l'URL de l'archive tar qui fonctionne bien avec yarn . S'installe plus rapidement aussi.

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

@milosivanovic, malheureusement, cette solution de contournement ne fonctionne pas pour nos URL internes au format:
git+ssh://[email protected]:team-name/repo.git

Si vous modifiez le dépôt initial au format ssh://source.com/team-name/repo.git ...

... alors cela fonctionnera pour la première ... mais bien sûr, toutes les autres dépendances internes que la première dépendance interne pointe pour la casser, puisqu'elles sont toutes dans ce format.

Sans passer par et modifier toutes les URL de tous nos dépôts et dépendances au format de solution de contournement (puis avoir à gérer cela ne fonctionne pas normalement sur npm), nous sommes également un peu bloqués à ce sujet.

Comme @ 131 l'a souligné, c'est une des principales façons dont les équipes utilisent npm en interne (à ma connaissance).

Ça a l'air génial en plus!

@brokenalarms le ssh://host.com/user/repo est entièrement rétrocompatible avec npm (tant que l'utilisateur attendu est spécifié dans le fichier de configuration SSH), mais c'est néanmoins un bon point.

Je vois .... donc ils savent juste quel utilisateur basé sur la clé ssh alors?

@ntucker oui

J'ai eu le même problème mais la solution de ntucker pour ajouter User git à ~ / .ssh / config m'a aidé. Au moins dans un environnement de développement. Je vais essayer de déployer sur AWS EB maintenant :)

Peut confirmer que l'utilisation de git+ssh://[email protected]:<org>/<repo> ne fonctionne pas dans yarn et le passage à https://github.com:<org>/<repo> fonctionne, mais cela échouera sur notre serveur CI qui utilise toujours _NPM _.

Cette solution de contournement m'a aidé:

  1. a changé l'URL de mon dépôt privé de
git+ssh://git@host/user/private-repo.git 

à

ssh://host/user/private-repo.git
  1. Ajout de l'utilisateur git à ~ / .ssh / config:
Host bitbucket.org
    User git

Host github.com
    User git

Quelqu'un a vérifié si les solutions de contournement fonctionnent avec bitbucket?

@tgarbiak - oui, j'utilise bitbucket.

En utilisant BitBucket, j'ai ajouté ceci à mon ~ / .ssh / config:

Host stash.company.com
    port 7999
    User shawn

Et utilisé du fil pour ajouter ce package:

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

Quand j'exécute npm install , cela fonctionne bien, mais quand j'exécute yarn install , j'obtiens cette erreur:

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)

Oui, comme indiqué précédemment, cette solution de contournement fonctionne.

Le fait est que cela va changer cela dans chacun de nos 50+
dépendances, et exigeant que chaque futur utilisateur prenne désormais les
étape de préparation de leur fichier de configuration ssh pour travailler avec le fil ou le
La configuration existante de npm n'est malheureusement pas une option.

Le mercredi 12 octobre 2016, 03:47 Sven Varkel [email protected] a écrit:

Cette solution de contournement m'a aidé:

  1. changé l'URL de mon dépôt privé de git + ssh: //git@host/user/private-repo.git
    à
    ssh: // hôte/user/private-repo.git
  2. Ajout de l'utilisateur git à ~ / .ssh / config:
    ''
    Hôte bitbucket.org
    Utilisateur git

Hébergeur github.com
Utilisateur git

-
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/513#issuecomment -253180666, ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AHC8CnUaBP_B_FL_AX1xL5FUrEWR-rnPks5qzLrTgaJpZM4KO4Cm
.

@diorman et quiconque lit ceci: Je vous recommande vivement de ne pas enregistrer le jeton github dans votre fichier package.json dans le contrôle de code source.

@jsdnxx merci d'avoir signalé cela. Je viens de me lancer dans un grand projet privé qui avait déjà le jeton sur le package.json pour les dépendances privées. Suivra vos conseils. Merci encore

Pour les branches, la solution de contournement de l'archive tar de https://github.com/yarnpkg/yarn/issues/513#issuecomment -253059522 ne semble pas fonctionner, peut-être en raison de la mise en cache. J'utilise Yaska/keystone#yaska-build comme nom de paquet à installer, et il utilise un mauvais commit, et quand on utilise https://github.com/Yaska/keystone/tarball/yaska-build il utilise toujours le mauvais commit. npm gère correctement.

Dans le même ordre d'idées, si j'ai yarn link ed une dépendance de repo privé localement, yarn ne devrait même pas vérifier si cette dépendance est dans le registre npm, mais actuellement yarn échoue dans ce cas sans aucun des solutions de contournement mentionnées dans ce fil.

La configuration proposée ~ / .ssh / config interrompt la résolution du paquet, donc ne fonctionne pas. Espérons que le PR qui corrige ce problème sera bientôt fusionné, sinon revenons au bon vieux NPM.

La solution de contournement pour gitlab utilise ce format:

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

Fonctionne aussi avec le référentiel privé, utilisez le jeton d'accès personnel Gitlab :

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

@Webysther - comme @jsdnxx l'a dit:

Je vous recommande vivement de ne pas archiver le jeton github dans votre fichier package.json dans le contrôle de code source.

Il en va évidemment de même pour GitLab ou tout autre jeton privé.

Private Token est juste pour param, une nouvelle version de Gitlab capable de gérer plusieurs jetons d'accès.
J'adorerais utiliser git + ssh dans yarn ...

Depuis Gitlab Docs:

Jetons d'accès personnels

Vous pouvez générer un jeton d'accès personnel pour chaque application que vous utilisez et qui a besoin d'accéder à l'API GitLab.

Jeton privé

Votre jeton privé est utilisé pour accéder aux ressources de l'application sans authentification.

J'ai jeté un œil au code et il me semble qu'une fois qu'un dépôt git a été
obtenu, son hachage de validation n'est plus vérifié, vous ne pouvez donc pas suivre une branche.

Est-ce une évaluation correcte, et si oui, cela appartient-il à un autre
problème?

Le ven 14 octobre 2016 à 6 h 52 Webysther Nunes [email protected]
a écrit:

Private Token est juste pour param, la nouvelle version de Gitlab peut gérer
jeton d'accès multiple.
J'adorerais utiliser git + ssh dans yarn ...

Depuis Gitlab Docs:
Jetons d'accès personnels

Vous pouvez générer un jeton d'accès personnel pour chaque application que vous utilisez
a besoin d'accéder à l'API GitLab.
Jeton privé

Votre jeton privé est utilisé pour accéder aux ressources de l'application sans
authentification.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/513#issuecomment -253709157, ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AADWlhxxjS7Kl1wt_Wm6UG1Q_7X86D7oks5qzwqYgaJpZM4KO4Cm
.

@wmertens Non, la version reste verrouillée à l'intérieur de yarn.lock. Essayez yarn upgrade

@Webysther hélas, yarn upgrade ne fait aucune différence. Il continue d'utiliser l'ancien commit. Je dois noter que la branche a été poussée de force, mais je ne pense pas que cela compte, car yarn devrait rechercher le commit correspondant à la balise donnée et l'installer, non?

J'ai trouvé une solution de contournement pour forcer le fil à récupérer le bon commit:

Supprimez le package de ~/.yarn-cache , puis exécutez yarn upgrade .

Il le récupérera et les choses sont comme elles devraient être. Est-il faux de s'attendre à ce que yarn upgrade vérifie les commits des dépôts git?

Je pense qu'il est correct que la mise à niveau de fil devrait vérifier les nouveaux commits git, mais cela devrait être une version par projet, et non mise en cache dans le répertoire personnel de l'utilisateur. Mais c'est aussi un bug séparé je pense

Nos projets ont des centaines d'entrées package.json du formulaire
"[name]": "[email protected]:[team]/[project].git"
Même erreur vue

Ce problème sera-t-il résolu par le PR # 971?

@BryanCrotaz Non, cela ne semble pas être une solution complète. Semble limité à GitHub. Les dépôts privés sont toujours un problème (ex. git+ssh://[email protected]:user/project.git#d6c5789 )

EDIT: Comme indiqué par @bdougherty ci-dessous, git+ssh://[email protected]/user/project.git#d6c5789 , avec un / au lieu de : précédant l'utilisateur, fonctionne.

+1

J'ai pu contourner ce problème en modifiant le format des URL de

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

à

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

Les deux formats sont valides dans npm et le seul problème est que toutes les dépendances doivent utiliser ce format.

@kittens Je pense que ça ( git+ssh://git@host/org/repo.git ) fonctionne pour moi maintenant?

fil : v0.16.1
nœud : v6.9.1


Je n'ai pas essayé git+ssh://git<strong i="13">@host</strong>:org/repo.git mais url.parse() ne semble pas ignorer entièrement le : , il peut donc être nécessaire de le supprimer:

> 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' }

Peut-être que https://github.com/yarnpkg/yarn/pull/934 a résolu ce

@ Fishrock123 Je peux confirmer ce qui semble fonctionner avec yarn v0.16.0 git + ssh package install.
Avec la v0.13.0, il échouait systématiquement avec error Couldn't find package "<package>" on the "npm" registry. pour les paquets git + ssh.

@ Fishrock123 Confirmé. Même ici, cela fonctionne maintenant.

Oui, le # 934 était destiné à résoudre ce problème :)

Cependant, le format suivant ne fonctionnera pas: git+ssh://git<strong i="6">@host</strong>:org/repo.git (avec un séparateur : )

Existe-t-il des informations sur la date à laquelle le support du séparateur : pourrait arriver?

Je travaillais sur quelque chose, mais je n'ai pas eu la chance de commencer quelques cas extrêmes. J'essaierai d'y arriver la semaine prochaine si personne ne me bat.

Eh bien, j'ai toujours un problème avec cela, mais probablement un peu différent. Je peux installer un seul paquet avec yarn add git+ssh://[email protected]/group/foo.git#0.0.4 et cela fonctionne énormément. Ensuite, je veux en installer un autre sur le même projet yarn add git+ssh://[email protected]/group/bar.git et soudainement je reçois Couldn't find package "group-foo" on the "npm" registry.

J'utilise la version 0.16. Dois-je plutôt créer un nouveau problème avec cela?

Edit: Vous voudrez peut-être ajouter que yarn.lock semble correct ...

"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: Peut-être en fait un problème dans package.json, cela ressemble à ceci après la première installation. De toute évidence, il a abandonné le protocole alors qu'il était conservé dans yarn.lock . Donc, je suppose qu'il ne peut tout simplement pas le trouver, alors il regarde plutôt dans npm.

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

+100

La mise à jour vers la v0.16.1 et l'utilisation de la syntaxe git+ssh://git@host/org/repo.git résolu le problème pour moi (note: ne fonctionnait toujours pas avec la syntaxe git+ssh://git<strong i="6">@host</strong>:org/repo.git )

Le but est sûrement de prendre en charge les fichiers package.json existants, sinon la migration est difficile et la double exécution pour les tests est impossible

En utilisant yarn 0.16.1 j'ai pu utiliser un dépôt privé avec la syntaxe git + ssh. En outre, il a utilisé correctement git @ user.

@fermuch Et pouvez-vous exécuter par exemple. yarn ls après une telle installation? À quoi ressemble votre package.json , l'URL du dépôt privé est-elle la même ou a-t-elle changé d'une manière ou d'une autre?

@FredyC ma sortie de 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]

Cela a été exécuté après la suppression de my-private-package de node_modules .
Après le yarn add , je peux voir correctement les fichiers dans node_modules .

Sorties du fil ls:

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

Je ne sais pas pourquoi cela donne 0.1.4 puisque le paquet n'existe pas dans le registre npm, et le paquet du github a la version 2.1.3 .

ÉDITER

De plus, il convient de noter que cela a été ajouté à mon yarn.lock :

"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 Oui, j'ai exactement le même problème là-bas. Je suis presque certain que si vous essayez d'ajouter un autre paquet maintenant (même un de npm), il échouera également. J'ai déjà créé un problème séparé pour cela ... # 1312

J'ai le même problème ici, mais avec l'url publique, pas sur ssh.

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

Salut à tous,

J'ai constaté que le problème était également lié à la version du nœud dont vous disposez.

J'utilise le format "git + ssh: //[email protected]//.git #". Je fais du développement sur OSX et CentOS 7. J'ai constaté qu'avec les dernières versions du nœud 4 (v4.6.1) et du nœud 6 (v6.9.1), le fil fonctionne sans problème avec ce format. Avec une ancienne version de node 4 (v4.4.5) cela fonctionne sur OSX mais pas sur CentOS 7. Plus précisément, lorsque le fil tente de télécharger le dépôt, il se bloque pour toujours. Si vous rencontrez le même problème, assurez-vous que vous utilisez la dernière version du nœud 4 ou 6.

En référence à kcormier, j'ai essayé à la fois le nœud 4.6.1 et le nœud 6.9.1 et aucun d'eux ne résout le problème de yarn ne pouvant pas trouver des versions taguées spécifiques d'un dépôt via SSH.

Le format qui échoue est:

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

Il donne toujours une erreur indiquant qu'il ne peut pas trouver une version qui correspond à la balise (fonctionne bien avec npm).

Je trouve que cela fonctionne bien si je change les deux points après le domaine en une barre oblique. Bizarre, non?

@alanhogan J'ai également remarqué que cela fonctionne bien si nous changeons le deux-points après le domaine en une barre oblique, mais si le package a d'autres dépendances git + ssh, vous devrez le changer dans le package.json de la bibliothèque / package en cours d'installation . Un autre problème est que même si vous remplacez les deux points par une barre oblique, une erreur sera déclenchée si vous essayez de référencer un commit ou une branche spécifique.

J'ai eu du succès en me référant aux branches et aux tags, moi-même. J'utilisais le nœud 6.9.1

Mais oui le problème récursif est réel, mais pas trop grave puisque en théorie seuls nos propres modules privés seront affectés.

@alanhogan ouais je suis confronté au même problème.

Le correctif ci-dessus ne semble pas fonctionner dans mon cas. J'ai forké un package Npm officiel dans mon repo, et quand je donne l'URL de mon repo, même avec un / au lieu de:, yarn résout le repo officiel. (officiel: https://github.com/TheLarkInn/angular2-template-loader, le mien: https://github.com/Krisa/angular2-template-loader). Je n'ai pas trouvé de solution de contournement (à côté de l'utilisation de Npm pour le moment).

Le passage d'une dépendance versionnée à une dépendance tarball nécessite un yarn cache clean avant de décompresser l'archive tar en tant que nouveau node_module (Node v6 LTS et yarn v0.16.1).

une armée de développeurs a voté cela, y a-t-il un moyen d'aider?

@ f-sign y travaille dans notre équipe. Avez-vous besoin de l'aide d'une armée, Flávio?

Une partie essentielle de ce problème semble être l'incohérence de package.json et yarn.lock comme décrit par @FredyC : Le package.json ne contient pas le préfixe git+ssh://git@ , qui est conservé dans yarn.lock pendant l'installation . Je pensais, ce fil préfère regarder le fichier yarn.lock plutôt que de récupérer les informations de résolution de package.json

Après avoir édité le package.json à la main et défini le préfixe, tout a bien fonctionné.

@maybeec Ce problème est en fait déjà résolu dans la branche master ... https://github.com/yarnpkg/yarn/issues/1312#issuecomment -258230803

Bravo, j'attends avec impatience la prochaine version. Je pense que cela résoudra beaucoup de problèmes.

Oui, je suis totalement convaincu de la difficulté de faire de nouvelles versions. Celui-ci dure environ un mois maintenant? Je suppose que c'est une politique Facebook stricte ou quoi ... 😢

1784 demande une nouvelle version. Veuillez simplement laisser une réaction de pouce en l'air!

Mon problème décrit un problème, qui est similaire, même si ce n'est pas le même. J'ai parcouru un peu le code et j'ai trouvé cette partie intéressante , qui est en fait utilisée sur chaque url git:

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

Soooo .... Quelqu'un peut-il me dire, quelle est la raison de la suppression du _git + _ pour chaque URL git passée à yarn? Je ne vois pas de vraie raison, et le code manque de documentation, alors peut-être que quelqu'un pourrait expliquer l'intention :)

1816 pourrait bien résoudre ce problème - jetez un œil aux changements de code - il résout certainement le problème avec les deux points après le domaine

Le problème semble être résolu sur le fil v0.17.0. J'ai pu obtenir l'un de mes référentiels Github privés sur une version spécifique.

Ce problème est-il résolu? J'essaye de migrer mon projet de npm vers yarn mais je suis toujours confronté à ce problème avec

@viswanathamsantosh semble travailler de mon côté

image

ressemble à cela est corrigé ici https://github.com/yarnpkg/yarn/pull/971 ! le remplacement de deux points (:) par une barre oblique (/) a réellement fonctionné. : ')

Le remplacement des deux points par une barre oblique ne fonctionne pas dans mon cas :( _git + ssh: //git@private..._ est toujours réduit à _ ssh: //git@private..._

Oui, j'ai toujours ce problème aussi, même avec la version 0.17.2 de Yarn. La partie git+ est supprimée et je me retrouve avec:

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

Étant donné que cela fonctionne pour certaines personnes, cela me rend confus. Une idée de ce que nous faisons mal?

placez ceci dans ~ / .ssh / config

Host github.com
        User git

Oui! Cela a résolu le problème pour moi. Merci.

Ce serait bien si cleanUrl ne fonctionnait pas, donc nous pourrions l'avoir directement dans l'URL à la place. Le fait de devoir modifier un fichier de configuration nécessite un changement de devops où nous pourrions sinon avoir un contrôle de version le gérer. Vous ne savez pas quel était le processus de réflexion derrière cela ...

Même problème ici. Les URL des référentiels privés ne fonctionnent plus comme avant (npm).

git + ssh: //[email protected] : ORG / repo.git devrait fonctionner car il doit être compatible avec npm pendant la phase de migration ...

@DominicBoettger Une fois que vous avez ajouté User git à votre ~/.ssh/config vous voudrez également changer ce deux-points en une barre oblique. D'après mon expérience d'aujourd'hui, Yarn ne joue pas encore bien avec le colon.

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

dépendances du formulaire

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

ne fonctionne pas pour moi avec le dernier fil 017.2 . L'erreur est:

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

Je n'ai pas encore testé les solutions de rechange, mais j'espère que le fil prendra éventuellement en charge la même syntaxe que NPM. Doit-il s'agir d'un nouveau problème ou est-ce toujours applicable à ce problème?

@sarus PR # 1816

Veuillez fusionner PR # 1816 et publier une nouvelle version 👍

Fusionner? Quelqu'un? NPM ME CONDUIT DES NOIX !! Veuillez fusionner et libérer :(

Ce problème persiste dans la v0.18.0.

L'appel de yarn install dans un projet propre, sans node_modules et sans fichier yarn.lock fonctionne. L'appeler à nouveau immédiatement après entraînera l'erreur «Impossible de résoudre le nom d'hôte».

J'ai découvert que la suppression du fichier yarn.lock fonctionne, donc je suppose qu'il y a soit quelque chose qui ne va pas dans le fichier de verrouillage ou la façon dont le fil se clone lors de la lecture à partir d'un fichier de verrouillage.

J'espère que cela t'aides!

Ce problème est celui-là même qui empêche de nombreux développeurs d'utiliser du fil.
Nous devons prendre ce problème au sérieux

@regou totalement d'accord mec ... C'est la seule raison pour laquelle je ne peux pas utiliser Yarn ...

Les gens, au lieu de ce jammage constant que personne ne travaille là-dessus, regardez simplement ce PR # 1816 et vous verrez qu'ils essaient de le fusionner ...

S'il vous plaît tout le monde, nous avons une solution à ce problème dans # 1816 sur laquelle Flavio et moi avons passé environ dix jours.

Cependant, un autre ensemble de tests échoue selon l'endroit où les tests sont exécutés.

Veuillez exécuter les tests sur votre machine et rapporter sur # 1816 les résultats que vous avez obtenus et la version de votre système d'exploitation et de votre nœud

Merci @FredyC & @BryanCrotaz pour avoir

Fixé via # 2384

Cette page vous a été utile?
0 / 5 - 0 notes