¿Tiene una reproducción que pueda usar literalmente? Tengo problemas para reproducir esto.

No lo siento.

Sin embargo, en realidad no fue de mi github personal. Es "git+ssh://[email protected]/<org>/<package>.git"

El repositorio es privado y tengo acceso de lectura / escritura. (Esto accede a través de una clave SSH registrada en mi cuenta de github)

¿Hay una salida de registro adicional que pueda obtener de alguna manera para usted?

Mencionaré que esto sucede con más de uno de esos identificadores.

Reproducción mínima:

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

El paquete no está en el registro, si eso marca la diferencia.

Esto también genera errores al especificar una etiqueta git (que permite npm).

Fragmento de ejemplo:

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

También recibo este # 621

Solo agregue en caso de que la sutileza sea diferente / requiere una solución adicional para el caso @BBB de la etiqueta git:

Estoy intentando instalar un _ hash de confirmación específico_ con git + ssh. El cliente predeterminado de NPM admite esto.

Parece que los números 573, 633 y 639 están relacionados

Para el contexto, de los documentos de

npm install <git remote url>:

Instala el paquete del proveedor de git alojado, clonándolo con git. Primero lo intenta a través de https (git con github) y si eso falla, a través de ssh.

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

<protocol> es uno de git , git+ssh , git+http , git+https o git+file . Si hay <commit-ish> se especifica, master se utiliza.

También debe tenerse en cuenta que <commit-ish> es una gama bastante amplia de valores resolubles.

Un objeto commit o un objeto que puede desreferenciarse recursivamente a un objeto commit . Las siguientes son todas confirmaciones: un objeto commit , un objeto tag que apunta a un objeto commit , un objeto tag que apunta a un tag objeto que apunta a un commit objeto, etc.

Nota: También se debe garantizar que estas instalaciones de URL remotas de git funcionen en instancias de servidor de git públicas y privadas utilizando claves SSH para la autenticación del servidor, no solo en GitHub / GitLab / etc. Podría imaginar un escenario en el que una empresa utiliza un servidor git local interno para todas sus dependencias administradas internamente (o incluso repositorios privados de GitHub a los que se accede a través de SSH). En este momento, yarn no está configurado para adaptarse a estos casos de uso _relativamente comunes_.

La forma más fácil de configurar un caso de reproducción sería intentar instalar un paquete desde un repositorio privado de GitHub usando Yarn.

Si especifica la siguiente cadena de origen:

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

entonces se hace intento de clonar el repositorio indicado a través de SSH, pero falla con "Permiso denegado (publickey)" porque GitHub espera clientes se registren como el git usuario, y en este caso el usuario cuenta local se utiliza por defecto .

Cuando especifica git@ para forzar a git a iniciar sesión como git en GitHub, entonces falla con lo habitual:

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

Entonces, casi funciona, pero no admite especificar el nombre de usuario. Si el usuario de su cuenta local se llamara git , entonces tendría éxito.

Si agrega lo siguiente a su archivo ~/.ssh/config :

Host github.com
        User git

puede forzar todos los inicios de sesión en github.com a través de SSH para usar el usuario git de forma predeterminada, y esto hace que el hilo pueda clonar desde repositorios privados cuando se usa el formato de origen ssh://github.com/<user>/<package> .

Este es un fuerte obstáculo para nosotros, el uso de repositorios referenciados a git (apuntando a nuestra instancia local de gitlab EE) es una parte importante de nuestro flujo de trabajo: cry:
También es muy útil para bifurcar y apuntar a paquetes "antes de fusionar y publicar npm" (por ejemplo, http-proxy ...)

@milosivanovic

Si agrega lo siguiente a su archivo ~ / .ssh / config:

Pero mi configuración ya tiene mis credenciales de autenticación ssh para github, por lo que puedo acceder a los repositorios privados. Esta solución solo funciona para repositorios públicos, ¿verdad?

@milosivanovic @ntucker en realidad esto funcionó en mi caso particular; No tenía ningún archivo de configuración ssh para empezar.

@kblcuk ah, bueno @milosivanovic estaba

@ntucker, la solución alternativa indicada es para repositorios privados. Si ya tiene una entrada Host github.com en ~/.ssh/config , agregue User git a esa entrada y el hilo podrá clonar cuando especifique una cadena de origen como ssh://github.com/<user>/<package> , es decir, sin "git +" y sin ningún usuario especificado.

@milosivanovic ¿Cómo sabe github mi nombre de usuario para realizar la autenticación ssh entonces?

@ntucker cuando se comunica a través de SSH, GitHub espera que inicie sesión en sus servidores como usuario "git". Si intenta iniciar sesión con su nombre de usuario habitual de GitHub, la autenticación fallará. GitHub sobre SSH te diferencia por tu clave pública, no por tu nombre de usuario. Referencia: https://help.github.com/articles/testing-your-ssh-connection/

Solo pensé en mencionarlo porque muchos probablemente no estén al tanto de esta característica. Para GitHub, también puede depender de la URL del tarball que funciona bien con yarn . También se instala más rápido.

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

@milosivanovic desafortunadamente, esta solución no funciona para nuestras URL internas en el formato:
git+ssh://[email protected]:team-name/repo.git

Si cambia el repositorio inicial al formato ssh://source.com/team-name/repo.git ...

... entonces funcionará para la inicial ... pero luego, por supuesto, todas las demás dependencias internas a las que apunta la primera dependencia interna la rompen, ya que todas están en ese formato.

Sin pasar y cambiar todas las URL en todos nuestros repositorios y dependencias al formato de solución alternativa (luego tener que lidiar con que no funcione normalmente en npm), también estamos un poco bloqueados en esto.

Como señaló @ 131 , esta es una de las principales formas en que los equipos usan npm internamente (que yo sepa).

¡Se ve muy bien además de eso!

@brokenalarms, el ssh://host.com/user/repo es totalmente compatible con npm (siempre que el usuario esperado esté especificado en el archivo de configuración SSH), pero ese es un punto justo.

Ya veo ... ¿entonces solo saben qué usuario basado en la clave ssh entonces?

@ntucker sí

Tuve el mismo problema, pero la solución de ntucker para agregar User git a ~ / .ssh / config me ayudó. Al menos en el entorno de desarrollo. Intentaremos implementar en AWS EB ahora :)

Puedo confirmar que usar git+ssh://[email protected]:<org>/<repo> no funciona en yarn y cambiar a https://github.com:<org>/<repo> sí funciona, pero eso fallará en nuestro servidor CI que todavía usa _NPM _.

Esta solución me ayudó:

1. cambió la URL de mi repositorio privado de

git+ssh://git@host/user/private-repo.git 

a

ssh://host/user/private-repo.git

1. Se agregó User git a ~ / .ssh / config:

Host bitbucket.org
    User git

Host github.com
    User git

¿Alguien comprobó si las soluciones alternativas funcionan con bitbucket?

@tgarbiak : sí, estoy usando bitbucket.

Usando BitBucket, agregué esto a mi ~ / .ssh / config:

Host stash.company.com
    port 7999
    User shawn

Y usé hilo para agregar este paquete:

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

Cuando ejecuto npm install , funciona bien, pero cuando ejecuto yarn install , aparece este error:

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)

Sí, como se indicó anteriormente, esta solución funciona.

El punto es que vamos a cambiar esto en cada uno de nuestros 50+
dependencias, y requiriendo que cada usuario futuro ahora tome el adicional
paso de preparar su archivo de configuración ssh para trabajar con hilo o el
La configuración existente de npm no es, lamentablemente, una opción.

El miércoles 12 de octubre de 2016 a las 3:47 a.m., Sven Varkel [email protected] escribió:

Esta solución me ayudó:

1. cambié la URL de mi repositorio privado de git + ssh: //git@host/user/private-repo.git
   a
   ssh: //host/user/private-repo.git
2. Se agregó User git a ~ / .ssh / config:
   ''
   Host bitbucket.org
   Usuario git

Anfitrión github.com
Usuario git

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/513#issuecomment -253180666, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AHC8CnUaBP_B_FL_AX1xL5FUrEWR-rnPks5qzLrTgaJpZM4KO4Cm
.

@diorman y cualquiera que lea esto: Recomiendo encarecidamente que no registre el token de github en su archivo package.json en el control de código fuente.

@jsdnxx gracias por señalar esto. Me lancé a un gran proyecto privado que ya tenía el token en package.json para dependencias privadas. Seguiremos tus consejos. Gracias de nuevo

Para las ramas, la solución alternativa del tarball de https://github.com/yarnpkg/yarn/issues/513#issuecomment -253059522 no parece funcionar, quizás debido al almacenamiento en caché. Yo uso Yaska/keystone#yaska-build como el nombre del paquete para instalar, y usa un compromiso incorrecto, y cuando uso https://github.com/Yaska/keystone/tarball/yaska-build todavía usa el compromiso incorrecto. npm maneja correctamente.

En una nota relacionada, si tengo yarn link ed una dependencia de repositorio privado localmente, yarn ni siquiera debería verificar si esa dependencia está en el registro npm, pero actualmente yarn está fallando en este caso sin ninguno de los soluciones alternativas mencionadas en este hilo.

La configuración propuesta ~ / .ssh / config rompe la resolución del paquete, por lo que no funciona. Con suerte, el PR que soluciona esto se fusionará pronto, de lo contrario, volverá al buen NPM.

La solución alternativa para gitlab es usar este formato:

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

También funciona con repositorio privado, use Gitlab Personal Access Token :

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

@Webysther - como dijo @jsdnxx :

Recomiendo encarecidamente que no registre el token de github en su archivo package.json en el control de código fuente.

Obviamente, lo mismo ocurre con GitLab o cualquier otro token privado.

Private Token es solo para param, la versión más nueva de Gitlab puede administrar token de acceso múltiple.
Me encantaría usar git + ssh en hilo ...

Desde Gitlab Docs:

Tokens de acceso personal

Puede generar un token de acceso personal para cada aplicación que use que necesite acceso a la API de GitLab.

Token privado

Su token privado se utiliza para acceder a los recursos de la aplicación sin autenticación.

Eché un vistazo al código y me parece que una vez que un repositorio de git ha sido
obtenido, su hash de confirmación ya no se verifica, por lo que no puede rastrear una rama.

¿Es esa una evaluación correcta y, de ser así, pertenece a una
¿problema?

El viernes 14 de octubre de 2016 a las 6:52 a.m. Webysther Nunes [email protected]
escribió:

Private Token es solo para param, la versión más nueva de Gitlab capaz de administrar
token de acceso múltiple.
Me encantaría usar git + ssh en hilo ...

Desde Gitlab Docs:
Tokens de acceso personal

Puede generar un token de acceso personal para cada aplicación que utilice que
necesita acceso a la API de GitLab.
Token privado

Su token privado se utiliza para acceder a los recursos de la aplicación sin
autenticación.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/513#issuecomment -253709157, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AADWlhxxjS7Kl1wt_Wm6UG1Q_7X86D7oks5qzwqYgaJpZM4KO4Cm
.

@wmertens No, la versión permanece bloqueada dentro de yarn.lock. Prueba yarn upgrade

@Webysther , ay, yarn upgrade no hace la diferencia. Sigue usando la confirmación anterior. Debo tener en cuenta que la rama fue empujada a la fuerza, pero no creo que eso importe, porque yarn debería buscar la confirmación que coincide con la etiqueta dada e instalarla, ¿verdad?

Encontré una solución para obligar a hilo a buscar la confirmación correcta:

Elimine el paquete de ~/.yarn-cache y luego ejecute yarn upgrade .

Lo buscará de nuevo y las cosas son como deberían ser. ¿Es incorrecto esperar que yarn upgrade verifique las confirmaciones de los repositorios de git?

Creo que es correcto que la actualización de yarn debería buscar nuevas confirmaciones de git, sin embargo, debería ser una versión por proyecto, no almacenada en caché en el directorio de inicio del usuario. Pero eso también es un error separado, creo

Nuestros proyectos tienen cientos de entradas package.json del formulario
"[name]": "[email protected]:[team]/[project].git"
Mismo error visto

¿Lo arreglará PR # 971?

@BryanCrotaz No, esa no parece ser una solución completa. Parece limitado a GitHub. Los repositorios privados siguen siendo un problema (por ejemplo, git+ssh://[email protected]:user/project.git#d6c5789 )

EDITAR: Como lo señala @bdougherty a continuación, git+ssh://[email protected]/user/project.git#d6c5789 , con un / lugar de : antes del usuario, funciona.

+1

Pude solucionar este problema cambiando el formato de las URL de

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

a

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

Ambos formatos son válidos en npm y el único inconveniente es que todas las dependencias deben usar ese formato.

@kittens Creo que esto ( git+ssh://git@host/org/repo.git ) funciona para mí ahora.

hilo : v0.16.1
nodo : v6.9.1

No probé git+ssh://git<strong i="13">@host</strong>:org/repo.git pero url.parse() no parece ignorar el : completo, por lo que es posible que deba eliminarse:

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

¿Quizás https://github.com/yarnpkg/yarn/pull/934 arregló esto inadvertidamente?

@ Fishrock123 Puedo confirmar qué con la instalación del paquete yarn v0.16.0 git + ssh parece funcionar.
Con v0.13.0 fallaba consistentemente con error Couldn't find package "<package>" on the "npm" registry. para paquetes git + ssh.

@ Fishrock123 Confirmado. Incluso aquí funciona ahora.

Sí, el # 934 tenía la intención de solucionar esto :)

Sin embargo, el siguiente formato no funcionará: git+ssh://git<strong i="6">@host</strong>:org/repo.git (con un separador de : )

¿Hay alguna información sobre qué tan pronto llegará el soporte del separador : ?

Estaba trabajando en algo, pero no he tenido la oportunidad de presentar algunos casos extremos. Intentaré hacerlo la semana que viene si nadie se me adelanta.

Bueno, todavía tengo un problema con esto, pero probablemente un poco diferente. Puedo instalar un solo paquete con yarn add git+ssh://[email protected]/group/foo.git#0.0.4 y funciona muy bien. Luego quiero instalar otro en el mismo proyecto yarn add git+ssh://[email protected]/group/bar.git y de repente obtengo Couldn't find package "group-foo" on the "npm" registry.

Estoy usando la versión 0.16. ¿Prefiero crear un nuevo problema con esto?

Editar: Es posible que desee agregar que yarn.lock ve bien ...

"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: podría ser un problema en package.json, se ve así después de la primera instalación. Obviamente ha eliminado el protocolo mientras que en yarn.lock se mantuvo. Así que supongo que simplemente no puede encontrarlo, por lo que busca en npm.

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

+100

Actualizar a v0.16.1 y usar la sintaxis git+ssh://git@host/org/repo.git solucionó el problema (nota: todavía no funcionaría con la sintaxis git+ssh://git<strong i="6">@host</strong>:org/repo.git )

El punto seguramente es admitir archivos package.json existentes; de lo contrario, la migración es difícil y la ejecución dual para la prueba es imposible

Usando yarn 0.16.1 pude usar un repositorio privado con la sintaxis git + ssh. Además, usó el usuario git @ correctamente.

@fermuch Y puedes ejecutar, por ejemplo. yarn ls después de dicha instalación? ¿Cómo se ve su package.json ¿La URL del repositorio privado es la misma o ha cambiado de alguna manera?

@FredyC mi salida 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]

Esto se ejecutó después de eliminar my-private-package de node_modules .
Después de yarn add , puedo ver los archivos correctamente dentro de node_modules .

Salidas de hilo 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

No estoy seguro de por qué da 0.1.4 ya que el paquete no existe en el registro npm, y el paquete de github tiene la versión 2.1.3 .

EDITAR

Además, vale la pena señalar que esto se agregó a mi 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 Sí, tengo exactamente el mismo problema allí. Estoy casi seguro de que si intenta agregar cualquier otro paquete allí ahora (incluso uno de npm), también fallará. Ya he creado un problema separado para esto ... # 1312

Tengo el mismo problema aquí, pero con la URL pública, no sobre ssh.

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

Hola a todos,

Descubrí que el problema también está relacionado con la versión de nodo que tienes.

Estoy usando el formato "git + ssh: //[email protected]//.git #". Hago desarrollo en OSX y CentOS 7. Descubrí que con las últimas versiones del nodo 4 (v4.6.1) y del nodo 6 (v6.9.1), Yarn funciona con este formato sin problemas. Con una versión anterior de node 4 (v4.4.5) funciona en OSX pero no en CentOS 7. Específicamente cuando yarn intenta descargar el repositorio, se cuelga para siempre.Si tiene el mismo problema, asegúrese de estar ejecutando la última versión del nodo 4 o 6.

En referencia a kcormier, probé tanto el nodo 4.6.1 como el nodo 6.9.1 y ninguno de ellos resuelve el problema de que el hilo no pueda encontrar versiones etiquetadas específicas de un repositorio a través de SSH.

El formato que falla es:

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

Todavía da un error de que no puede encontrar una versión que coincida con la etiqueta (funciona bien con npm).

Encuentro que funciona bien si cambio los dos puntos después del dominio a una barra. Extraño, ¿verdad?

@alanhogan También he notado que funciona bien si cambiamos los dos puntos después del dominio a una barra, pero si el paquete tiene otras dependencias de git + ssh, tendrá que cambiarlo en el package.json de la biblioteca / paquete que se está instalando . Otro problema es que incluso si cambia los dos puntos a una barra, se activará un error si intenta hacer referencia a una confirmación o rama específica.

Yo mismo he tenido éxito al referirme a ramas y etiquetas. Estaba usando el nodo 6.9.1

Pero sí, el problema de la recursividad es real, aunque no está mal ya que en teoría solo se verán afectados nuestros propios módulos privados.

@alanhogan sí, estoy enfrentando el mismo problema.

La solución anterior no parece funcionar en mi caso. He bifurcado un paquete Npm oficial en mi repositorio, y cuando doy la URL de mi repositorio, incluso con un / en lugar de:, yarn está resolviendo el repositorio oficial. (oficial: https://github.com/TheLarkInn/angular2-template-loader, el mío: https://github.com/Krisa/angular2-template-loader). No pude encontrar una solución alternativa (además de usar Npm por el momento).

Cambiar de una dependencia versionada a una dependencia tarball requiere yarn cache clean antes de que realmente descomprima el tarball como el nuevo node_module (Node v6 LTS e yarn v0.16.1).

un ejército de desarrolladores ha votado a favor de esto, ¿hay alguna forma en que podamos ayudar?

@ f-sign está trabajando en ello en nuestro equipo. ¿Algo en lo que quieras ayuda de un ejército, Flávio?

Una parte esencial de este problema parece ser la inconsistencia de package.json y yarn.lock como lo describe @FredyC : el package.json no contiene el prefijo git+ssh://git@ , que se mantiene en yarn.lock durante la instalación . Estaba pensando que yarn prefiere mirar el archivo yarn.lock en lugar de recuperar la información de resolución de package.json

Después de editar el package.json a mano y configurar el prefijo, todo funcionó bien.

@maybeec Ese problema ya está resuelto en la rama maestra ... https://github.com/yarnpkg/yarn/issues/1312#issuecomment -258230803

Bien hecho, espero con ansias el próximo lanzamiento. Creo que solucionará muchos problemas.

Sí, estoy totalmente desconcertado cuál es el problema con hacer nuevos lanzamientos. ¿Este es como un mes ahora? Supongo que es una política estricta de Facebook o qué ... 😢

1784 solicita una nueva publicación. ¡Por favor, deje una reacción de aprobación!

Mi problema describe un problema, que es similar, aunque no el mismo. Revisé un poco el código y encontré esta parte interesante , que en realidad se usa en cada URL de git:

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

Soooo .... ¿Alguien puede decirme cuál es la razón para eliminar el _git + _ para cada URL de git que se pasa a hilo? No veo una razón real, y el código carece de documentación, así que tal vez alguien podría explicar la intención :)

1816 bien puede solucionar esto - eche un vistazo a los cambios de código - ciertamente soluciona el problema con los dos puntos después del dominio

El problema parece estar solucionado en yarn v0.17.0. Pude obtener uno de mis repositorios privados de Github en una versión específica.

¿Se solucionó este problema? Estoy tratando de migrar mi proyecto de npm a yarn, ¡pero sigo enfrentando este problema con [email protected] !

@viswanathamsantosh Parece trabajar de mi lado

parece que esto se solucionó aquí https://github.com/yarnpkg/yarn/pull/971 ! Reemplazar dos puntos (:) con barra (/) realmente funcionó. : ')

Reemplazar los dos puntos con una barra inclinada no funciona en mi caso :( _git + ssh: //git@private..._ todavía se reduce a _ ssh: //git@private..._

Sí, sigo teniendo este problema también, incluso con la versión 0.17.2 de Yarn. La parte git+ se elimina y termino con:

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

Dado que funciona para algunas personas, me confunde. ¿Alguna idea de lo que estamos haciendo mal?

coloque esto en ~ / .ssh / config

Host github.com
        User git

¡Si! Eso me lo arregló. Gracias.

Sin embargo, sería bueno si cleanUrl no se estuvieran ejecutando, por lo que podríamos tener esto directamente en la URL. Tener que cambiar un archivo de configuración requiere un cambio de devops donde de otra manera podríamos tener control de versiones manejándolo. ¿No estás seguro de cuál fue el proceso de pensamiento detrás de esto ...?

El mismo problema aqui. Las URL de los repositorios privados no funcionan como antes (npm).

git + ssh: //[email protected] : ORG / repo.git debería funcionar, ya que es necesario que sea compatible con npm durante la fase de migración ...

@DominicBoettger Una vez que haya agregado User git a su ~/.ssh/config , también querrá cambiar los dos puntos por una barra diagonal. En mi experiencia actual, Yarn todavía no funciona bien con el colon.

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

dependencias del formulario

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

no me funciona con la última lana 017.2 . El error es:

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

Aún no he probado las soluciones alternativas, pero espero que el hilo eventualmente admita la misma sintaxis que NPM. ¿Debería tratarse de un problema nuevo o todavía se aplica a este problema?

@sarus PR # 1816 solucionará esto

Combine PR # 1816 y publique una nueva versión 👍

¿Unir? ¿Alguien? ¡¡NPM ME ESTÁ CONDUCCIÓN LOCA !! Fusionar y liberar :(

Este problema permanece en v0.18.0.

Llamar a yarn install en un proyecto limpio, sin node_modules y el archivo yarn.lock funciona. Si lo vuelve a llamar inmediatamente después, aparecerá el error "No se pudo resolver el nombre de host".

Descubrí que la eliminación del archivo yarn.lock funciona, así que supongo que hay algo mal en el archivo de bloqueo o la forma en que el hilo se clona al leer un archivo de bloqueo.

¡Espero que esto ayude!

Este problema es el que impide que muchos desarrolladores utilicen hilo.
Necesitamos tomar este problema en serio

@regou totalmente de acuerdo hombre ... Esta es la única razón por la que no puedo usar Yarn ...

Gente, en lugar de este constante grito de que nadie trabaja en esto, solo mire el PR # 1816 y verá que están tratando de fusionarlo ...

Por favor, todos tenemos una solución para esto en el n. ° 1816 en el que Flavio y yo pasamos unos diez días.

Sin embargo, un conjunto diferente de pruebas falla dependiendo de dónde se ejecuten.

Ejecute las pruebas en su máquina e informe sobre # 1816 qué resultados obtuvo y cuál es su sistema operativo y versión de nodo

Gracias @FredyC y @BryanCrotaz por señalar a todos el # 1816. Estoy bloqueando este hilo por el momento.

Corregido a través de # 2384