Você tem um repro que eu possa usar na íntegra? Tendo problemas para reproduzir isso.

Não, desculpe.

Na verdade, não era do meu github pessoal. É "git+ssh://[email protected]/<org>/<package>.git"

O repo é privado e tenho acesso de leitura / gravação. (Isso acessa por meio de uma chave SSH registrada na minha conta do github)

Existe saída de log adicional que posso obter de alguma forma para você?

Mencionarei que isso acontece com mais de um identificador.

Repro mínimo:

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

O pacote não está no registro, se isso fizer diferença.

Isso também apresenta erros ao especificar uma tag git (que o npm permite).

Snippet de exemplo:

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

Eu também recebo este # 621

Apenas adicionar caso a sutileza seja diferente / requer uma solução adicional para o caso @BBB da tag git:

Estou tentando instalar um _specific commit hash_ com git + ssh. O cliente padrão NPM oferece suporte para isso.

Parece que # 573, # 633 e # 639 estão relacionados

Para contexto, a partir dos documentos do NPM :

npm install <git remote url>:

Instala o pacote do provedor git hospedado, clonando-o com git. Primeiro ele tenta via https (git com github) e se falhar, via ssh.

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

<protocol> é um de git , git+ssh , git+http , git+https , ou git+file . Se nenhum <commit-ish> for especificado, então master será usado.

Também deve ser notado que <commit-ish> é uma grande variedade de valores resolvíveis.

Um objeto commit ou um objeto que pode ser referenciado recursivamente para um objeto commit . A seguir estão todos os commit-ishes: um objeto commit , um objeto tag que aponta para um objeto commit , um objeto tag que aponta para um tag objeto que aponta para um objeto commit , etc.

Observação: essas instalações de url remoto git também devem funcionar em instâncias públicas e privadas do servidor git usando chaves SSH para autenticação de servidor, não apenas GitHub / GitLab / etc. Você pode imaginar um cenário em que uma empresa usa um servidor git local interno para todas as suas dependências gerenciadas internamente (ou até mesmo repositórios GitHub privados acessados ​​via SSH). No momento, yarn não está configurado para acomodar esses casos de uso _relativamente comuns_.

A maneira mais fácil de configurar um caso de reprodução seria tentar instalar um pacote de um repositório GitHub privado usando Yarn.

Se você especificar a seguinte string de origem:

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

em seguida, ele faz tentativa de clonar o repositório indicado por SSH, mas falha com "Permissão negada (publickey)" porque GitHub espera que os clientes de login como o git usuário, e neste caso o usuário conta local foi usado por padrão .

Quando você especifica git@ para forçar o git a fazer o login como git no GitHub, ele falha com o normal:

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

Então, quase funciona, mas não suporta a especificação do nome de usuário. Se o usuário da sua conta local fosse chamado de git , então ele realmente funcionaria.

Se você adicionar o seguinte ao seu arquivo ~/.ssh/config :

Host github.com
        User git

você pode forçar todos os logins para github.com via SSH para usar o usuário git por padrão, e isso torna o yarn capaz de clonar de repositórios privados ao usar o formato de origem ssh://github.com/<user>/<package> .

Este é um forte impedimento para nós, usar repositórios referenciados por git (apontando nossa instância local do gitlab EE) é uma parte importante de nosso fluxo de trabalho: cry:
Também é muito útil para bifurcar e apontar para pacotes "antes de mesclar e publicar npm" (por exemplo, http-proxy ...)

@milosivanovic

Se você adicionar o seguinte ao seu arquivo ~ / .ssh / config:

Mas minha configuração já tem minhas credenciais de autenticação ssh para github para que eu possa acessar os repositórios privados. Esta solução alternativa só funciona para repositórios públicos, certo?

@milosivanovic @ntucker na verdade isso funcionou no meu caso particular; Eu não tinha nenhum arquivo de configuração ssh para começar.

@kblcuk ah, bem, @milosivanovic estava indo para outros problemas e alegando que sua solução alternativa funcionou para esses casos, então eu percebi que esse era o problema para os problemas gerais com urls git.

@ntucker a solução alternativa declarada é para repositórios privados. Se você já tem uma entrada Host github.com em ~/.ssh/config , adicione User git a essa entrada e o yarn poderá clonar quando você especificar uma string de origem, como ssh://github.com/<user>/<package> , ou seja, sem "git +" e sem nenhum usuário especificado.

@milosivanovic Como o github sabe meu nome de usuário para fazer autenticação ssh então?

@ntucker ao se comunicar por SSH, o GitHub espera que você faça login em seus servidores como o usuário "git". Se você tentar fazer login com seu nome de usuário normal do GitHub, a autenticação falhará. GitHub sobre SSH diferencia você por sua chave pública, não por nome de usuário. Referência: https://help.github.com/articles/testing-your-ssh-connection/

Só pensei em mencionar porque muitos provavelmente não estão cientes desse recurso. Para GitHub, você também pode depender do URL do tarball, que funciona bem com yarn . Instala mais rápido também.

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

@milosivanovic, infelizmente, esta solução alternativa não funciona para nossos urls internos no formato:
git+ssh://[email protected]:team-name/repo.git

Se você alterar o repositório inicial para o formato ssh://source.com/team-name/repo.git ...

... então vai funcionar para o inicial ... mas então é claro que todas as outras dependências internas que a primeira dependência interna aponta para quebrá-lo, já que estão todas nesse formato.

Sem passar e alterar todas as URLs em todos os nossos repositórios e dependências para o formato de solução alternativa (então ter que lidar com isso não funcionando no npm normalmente), estamos um pouco bloqueados nisso também.

Como @ 131 apontou, esta é a principal maneira que as equipes usam o npm internamente (que eu saiba).

Além disso, parece ótimo!

@brokenalarms o formato ssh://host.com/user/repo é totalmente compatível com as versões anteriores do npm (contanto que o usuário esperado seja especificado no arquivo de configuração SSH), mas isso é um ponto justo, no entanto.

Entendo .... então eles apenas sabem qual usuário é baseado na chave ssh?

@ntucker sim

Eu tive o mesmo problema, mas a solução do ntucker para adicionar o usuário git a ~ / .ssh / config me ajudou. Pelo menos em ambiente de desenvolvimento. Vou tentar implantar no AWS EB agora :)

Pode confirmar que usar git+ssh://[email protected]:<org>/<repo> não funciona em yarn e mudar para https://github.com:<org>/<repo> funciona, mas isso irá falhar em nosso servidor de CI que ainda usa _NPM _.

Esta solução alternativa me ajudou:

1. mudei meu URL de repositório privado de

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

para

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

1. Usuário git adicionado a ~ / .ssh / config:

Host bitbucket.org
    User git

Host github.com
    User git

Alguém verificou se as soluções alternativas funcionam com o bitbucket?

@tgarbiak - sim, estou usando o bitbucket.

Usando o BitBucket, adicionei isso ao meu ~ / .ssh / config:

Host stash.company.com
    port 7999
    User shawn

E usei fios para adicionar este pacote:

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

Quando executo npm install , funciona bem, mas quando executo yarn install , recebo este erro:

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)

Sim, conforme indicado anteriormente, esta solução alternativa funciona.

A questão é que isso vai mudar em cada um de nossos mais de 50
dependências, e exigindo que cada usuário futuro agora tome o adicional
etapa de preparação de seu arquivo de configuração ssh para funcionar com o yarn ou o
A configuração do npm existente infelizmente não é uma opção.

Na quarta-feira, 12 de outubro de 2016, 03h47, Sven Varkel [email protected] escreveu:

Esta solução alternativa me ajudou:

1. alterei o URL do meu repositório privado de git + ssh: //git@host/user/private-repo.git
   para
   ssh: //host/user/private-repo.git
2. Usuário git adicionado a ~ / .ssh / config:
   ``
   Host bitbucket.org
   Usuário git

Host github.com
Usuário git

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/513#issuecomment -253180666 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AHC8CnUaBP_B_FL_AX1xL5FUrEWR-rnPks5qzLrTgaJpZM4KO4Cm
.

@diorman & qualquer um que leia isto: Eu recomendo fortemente que você não verifique o token do github em seu arquivo package.json no controle de origem.

@jsdnxx obrigado por apontar isso. Acabei de entrar em um grande projeto privado que já tinha o token no package.json para dependências privadas. Seguirá seu conselho. obrigado novamente

Para branches, a solução alternativa do tarball de https://github.com/yarnpkg/yarn/issues/513#issuecomment -253059522 não parece funcionar, talvez devido ao cache. Eu uso Yaska/keystone#yaska-build como o nome do pacote a instalar, e ele usa um commit errado, e quando usa https://github.com/Yaska/keystone/tarball/yaska-build ele ainda usa o commit errado. npm lida corretamente.

Em uma nota relacionada, se eu tiver yarn link ed uma dependência de repo privada localmente, o yarn não deve nem verificar se essa dependência está no registro npm, mas atualmente o yarn está falhando neste caso sem nenhum dos soluções alternativas mencionadas neste tópico.

A configuração ~ / .ssh / config proposta quebra a resolução de pacotes, portanto não funciona. Esperançosamente, o PR que corrige isso será fundido em breve, caso contrário, de volta ao bom e velho NPM.

A solução alternativa para o gitlab é usar este formato:

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

Funciona também com repositório privado, use o token de acesso pessoal Gitlab :

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

@Webysther - como @jsdnxx disse:

Eu recomendo fortemente que você não faça check-in do token github em seu arquivo package.json no controle de origem.

O mesmo, obviamente, vale para GitLab ou qualquer outro tokens privado.

Private Token é apenas para param, a versão mais recente do Gitlab capaz de gerenciar token de acesso múltiplo.
Adoraria usar git + ssh no yarn ...

Do Gitlab Docs:

Tokens de acesso pessoal

Você pode gerar um token de acesso pessoal para cada aplicativo que usar e que precise de acesso à API GitLab.

Token privado

Seu token privado é usado para acessar recursos de aplicativos sem autenticação.

Dei uma olhada no código e me parece que uma vez que um repositório git foi
obtido, seu hash de commit não é mais verificado, então você não pode rastrear um branch.

Essa é uma avaliação correta e, em caso afirmativo, isso pertence a um diferente
questão?

Na sexta-feira, 14 de outubro de 2016 às 6h52 Webysther Nunes [email protected]
escrevi:

Token privado é apenas para param, a versão mais recente do Gitlab capaz de gerenciar
token de acesso múltiplo.
Adoraria usar git + ssh no yarn ...

Do Gitlab Docs:
Tokens de acesso pessoal

Você pode gerar um token de acesso pessoal para cada aplicativo que usar
precisa de acesso à API GitLab.
Token privado

Seu token privado é usado para acessar recursos do aplicativo sem
autenticação.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/yarnpkg/yarn/issues/513#issuecomment -253709157 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AADWlhxxjS7Kl1wt_Wm6UG1Q_7X86D7oks5qzwqYgaJpZM4KO4Cm
.

@wmertens Não, a versão permanece bloqueada dentro de yarn.lock. Experimente yarn upgrade

@Webysther , infelizmente, yarn upgrade não faz diferença. Ele continua usando o antigo commit. Devo observar que o branch foi empurrado à força, mas não acho que isso importe, porque o yarn deve procurar o commit correspondente à tag dada e instalar isso, certo?

Eu encontrei uma solução alternativa para forçar o yarn a buscar o commit correto:

Remova o pacote de ~/.yarn-cache e execute yarn upgrade .

Ele irá buscá-lo novamente e as coisas são como deveriam ser. É errado esperar que yarn upgrade verifique os commits dos repositórios git?

Eu acho que é correto que a atualização do yarn deve verificar se há novos git commits, no entanto, isso deve ser uma versão por projeto, não em cache no diretório inicial do usuário. Mas isso também é um bug separado, eu acho

Nossos projetos têm centenas de entradas package.json do formulário
"[name]": "[email protected]:[team]/[project].git"
Mesmo erro visto

Isso será corrigido pelo PR # 971?

@BryanCrotaz Não, isso não parece ser uma solução completa. Parece limitado ao GitHub. Os repositórios privados ainda são um problema (por exemplo, git+ssh://[email protected]:user/project.git#d6c5789 )

EDITAR: Como apontado por @bdougherty abaixo, git+ssh://[email protected]/user/project.git#d6c5789 , com / vez de : precedendo o usuário, funciona.

+1

Consegui contornar esse problema alterando o formato dos urls de

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

para

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

Ambos os formatos são válidos em npm e o único problema é que todas as dependências precisam usar esse formato.

@kittens , acho que isso ( git+ssh://git@host/org/repo.git ) funciona para mim agora?

fio : v0.16.1
nó : v6.9.1

Não tentei git+ssh://git<strong i="13">@host</strong>:org/repo.git mas url.parse() não parece ignorar : inteiramente, portanto, pode ser necessário removê-lo:

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

Talvez https://github.com/yarnpkg/yarn/pull/934 corrigiu isso inadvertidamente?

@ Fishrock123 Posso confirmar que a instalação do pacote yarn v0.16.0 git + ssh parece funcionar.
Com a v0.13.0 estava falhando consistentemente com error Couldn't find package "<package>" on the "npm" registry. para pacotes git + ssh.

@ Fishrock123 Confirmado. Mesmo aqui funciona agora.

Sim, # 934 tinha como objetivo corrigir isso :)

No entanto, o seguinte formato não funcionará: git+ssh://git<strong i="6">@host</strong>:org/repo.git (com um separador : )

Existe alguma informação sobre quando o suporte do separador : estará chegando?

Eu estava trabalhando em algo, mas não tive chance de primeiro alguns casos extremos. Vou tentar fazer isso na próxima semana, se ninguém me vencer.

Bem, eu ainda tenho um problema com isso, mas provavelmente um pouco diferente. Posso instalar um único pacote com yarn add git+ssh://[email protected]/group/foo.git#0.0.4 e funciona muito bem. Então quero instalar outro para o mesmo projeto yarn add git+ssh://[email protected]/group/bar.git e de repente estou recebendo Couldn't find package "group-foo" on the "npm" registry.

Estou usando a versão 0.16. Devo criar um novo problema com isso?

Editar: pode querer adicionar que yarn.lock parece ok ...

"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: pode haver realmente um problema no package.json, parece assim após a primeira instalação. Obviamente, ele abandonou o protocolo enquanto em yarn.lock ele era mantido. Então eu acho que ele simplesmente não consegue encontrar, então parece que está em npm.

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

+100

Atualizar para v0.16.1 e usar a sintaxe git+ssh://git@host/org/repo.git corrigiu o problema para mim (nota: ainda não funcionaria com a sintaxe git+ssh://git<strong i="6">@host</strong>:org/repo.git )

O ponto certamente é oferecer suporte a arquivos package.json existentes, caso contrário, a migração é difícil e a execução dupla para teste impossível

Usando yarn 0.16.1 , consegui usar um repositório privado com a sintaxe git + ssh. Além disso, ele usou o usuário git @ corretamente.

@fermuch E você pode executar, por exemplo. yarn ls após tal instalação? Qual é a aparência do seu package.json , o url para o repositório privado é o mesmo ou foi alterado de alguma forma?

@FredyC minha saída 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]

Isso foi executado após a exclusão de my-private-package de node_modules .
Depois de yarn add , posso ver os arquivos corretamente dentro de node_modules .

Saídas do Yarn 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

Não tenho certeza por que dá 0.1.4 já que o pacote não existe no registro npm e o pacote do github tem a versão 2.1.3 .

EDITAR

Além disso, é importante notar que isso foi adicionado ao meu 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 Sim, tenho exatamente o mesmo problema lá. Tenho quase certeza de que, se você tentar adicionar qualquer outro pacote lá agora (mesmo um do npm), ele também falhará. Já criei um problema separado para este ... # 1312

Estou com o mesmo problema aqui, mas com a url pública, não sobre ssh.

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

Olá a todos,

Descobri que o problema também está relacionado à versão de nó que você possui.

Estou usando o formato "git + ssh: //[email protected]//.git #". Eu faço desenvolvimento em OSX e CentOS 7. Descobri que com as versões mais recentes do nó 4 (v4.6.1) e nó 6 (v6.9.1) o yarn funciona com este formato sem problemas. Com uma versão mais antiga do nó 4 (v4.4.5) funciona no OSX, mas não no CentOS 7. Especificamente quando o yarn tenta fazer o download do repo, ele trava para sempre. Se você estiver tendo o mesmo problema, certifique-se de estar executando a versão mais recente do nó 4 ou 6.

Em referência ao kcormier, tentei o nó 4.6.1 e o nó 6.9.1 e nenhum deles resolve o problema de o yarn não ser capaz de encontrar versões específicas com tags de um repo sobre SSH.

O formato que falha é:

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

Ainda dá um erro que não consegue encontrar uma versão que corresponda à tag (funciona bem com npm).

Acho que funciona bem se eu alterar os dois pontos após o domínio para uma barra. Estranho, certo?

@alanhogan Também notei que funciona bem se mudarmos os dois pontos após o domínio para uma barra, mas se o pacote tiver outras dependências git + ssh, você terá que alterá-lo no package.json da biblioteca / pacote sendo instalado . Outro problema é que mesmo se você alterar os dois pontos para uma barra, um erro será disparado se você tentar fazer referência a um commit ou branch específico.

Eu mesmo tive sucesso referindo-me a branches e tags. Eu estava usando o nó 6.9.1

Mas sim, o problema recursivo é real, embora não seja tão ruim, pois em teoria apenas nossos próprios módulos privados serão afetados.

@alanhogan sim, estou enfrentando o mesmo problema.

A correção acima não parece funcionar no meu caso. Fiz um bifurcação de um pacote Npm oficial em meu repo e, quando forneço a URL do meu repo, mesmo com / em vez de:, o yarn está resolvendo o repo oficial. (oficial: https://github.com/TheLarkInn/angular2-template-loader, meu: https://github.com/Krisa/angular2-template-loader). Não consegui encontrar uma solução alternativa (além de usar Npm no momento).

Mudar de uma dependência com versão para uma dependência de tarball requer yarn cache clean antes de realmente descompactar o tarball como o novo node_module (Node v6 LTS e yarn v0.16.1).

um exército de desenvolvedores votou nisso, há uma maneira de ajudarmos?

@ f-sign está trabalhando nisso em nossa equipe. Quer ajuda de um exército, Flávio?

Uma parte essencial deste problema parece ser a inconsistência de package.json e yarn.lock conforme descrito por @FredyC : O package.json não contém o prefixo git+ssh://git@ , que é mantido em yarn.lock durante a instalação . Eu estava pensando que o yarn está preferindo olhar para o arquivo yarn.lock em vez de recuperar as informações de resolução do package.json

Depois de editar o package.json manualmente e definir o prefixo, tudo funcionou bem.

@maybeec Esse problema já foi resolvido no branch master ... https://github.com/yarnpkg/yarn/issues/1312#issuecomment -258230803

Muito bem, estou ansioso pelo próximo lançamento. Acho que vai resolver muitos problemas.

Sim, estou totalmente confuso sobre qual é o atraso em fazer novos lançamentos. Este está em torno de um mês agora? Acho que é uma política rígida do Facebook ou o que ... 😢

1784 solicita um novo lançamento. Por favor, deixe uma reação positiva!

Meu problema descreve um problema, que é semelhante, embora não seja o mesmo. Eu examinei o código um pouco e encontrei esta parte interessante , que é realmente usada em cada url git:

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

Entããão .... Alguém pode me dizer qual é a razão para remover o _git + _ para cada url git passado para o yarn? Não vejo um motivo real, e falta documentação ao código, então talvez alguém possa explicar a intenção :)

1816 pode muito bem consertar isso - dê uma olhada nas alterações de código - certamente corrige o problema com dois pontos após o domínio

O problema parece ter sido corrigido no yarn v0.17.0. Consegui obter um de meu repositório Github privado em uma versão específica.

Este problema foi corrigido? Estou tentando migrar meu projeto de npm para yarn, mas ainda enfrento esse problema com [email protected] !

@viswanathamsantosh parece funcionar do meu lado

parece que isso foi corrigido aqui https://github.com/yarnpkg/yarn/pull/971 ! substituir dois pontos (:) por barra (/) realmente funcionou. : ')

Substituir os dois pontos por uma barra não funciona no meu caso :( _git + ssh: //git@private..._ ainda é reduzido para _ ssh: //git@private..._

Sim, ainda estou tendo esse problema também, mesmo com a versão 0.17.2 do Yarn. A parte git+ é removida e eu acabo com:

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

Dado que está funcionando para algumas pessoas, me deixa confuso. Alguma ideia do que estamos fazendo de errado?

coloque isso em ~ / .ssh / config

Host github.com
        User git

Sim! Isso resolveu para mim. Obrigado.

No entanto, seria bom se cleanUrl não estivesse sendo executado, então poderíamos ter isso diretamente no URL. Ter que mudar um arquivo de configuração requer uma mudança de devops onde poderíamos ter controle de versão lidando com isso. Não tem certeza de qual foi o processo de pensamento por trás disso ...?

Mesmo problema aqui. Urls de repositórios privados não estão funcionando como antes (npm).

git + ssh: //[email protected] : ORG / repo.git deve funcionar, pois é necessário para ser compatível com npm durante a fase de migração ...

@DominicBoettger Depois de adicionar User git ao seu ~/.ssh/config você também deseja alterar esses dois pontos para uma barra. Na minha experiência hoje, o Yarn não joga bem com o cólon ainda.

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

dependências do formulário

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

não funcione para mim com o fio mais recente 017.2 . O erro é:

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

Ainda não testei a solução alternativa, mas espero que o yarn suporte a mesma sintaxe do NPM. Deve ser um problema novo ou ainda é aplicável a este problema?

@sarus PR # 1816 vai consertar isso

Junte PR # 1816 e publique uma nova versão 👍

Unir? Alguém? NPM ESTÁ ME ENGANANDO !! Unifique e libere :(

Esse problema permanece na v0.18.0.

Chamar yarn install em um projeto limpo, sem node_modules e arquivo yarn.lock funciona. Chamá-lo novamente imediatamente depois resultará no erro "Não foi possível resolver o nome do host".

Descobri que remover o arquivo yarn.lock funciona, então presumo que haja algo errado no arquivo de bloqueio ou na maneira como o yarn clona ao ler um arquivo de bloqueio.

Espero que isto ajude!

Este é o problema que impede muitos desenvolvedores de usar fios.
Precisamos levar esse problema a sério

@regou concordo totalmente cara ... Esta é a única razão pela qual eu não posso usar o Yarn ...

Gente, em vez dessa reclamação constante de que ninguém trabalha nisso, basta observar aquele PR # 1816 mencionado e verá que eles estão tentando mesclá-lo ...

Por favor a todos nós temos uma correção para isso no # 1816 que Flavio e eu passamos cerca de dez dias.

No entanto, um conjunto diferente de testes falha dependendo de onde os testes são executados.

Por favor, execute os testes em sua máquina e relate no # 1816 quais resultados você obteve e qual é o seu sistema operacional e versão do nó

Obrigado @FredyC e @BryanCrotaz por apontar a todos para # 1816. Estou bloqueando este tópico por enquanto.

Corrigido via # 2384