У вас есть репродукция, которую я могу использовать дословно? Возникли проблемы с воспроизведением этого.

Нет извините.

Хотя на самом деле это не было из моего личного github. Это "git+ssh://[email protected]/<org>/<package>.git"

Репо является частным, и у меня есть доступ для чтения и записи. (Он получает доступ к нему через ключ SSH, зарегистрированный в моей учетной записи github)

Могу ли я как-нибудь получить для вас дополнительный вывод журнала?

Я отмечу, что это происходит с более чем одним таким идентификатором.

Минимальное воспроизведение:

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

Пакет отсутствует в реестре, если это имеет значение.

Это также ошибки при указании тега git (что позволяет npm).

Пример фрагмента:

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

Я тоже получаю это # ​​621

Просто добавление в случае, если тонкость отличается / требует дополнительного решения для случая @BBB тега git:

Я пытаюсь установить _зависимый хеш_ фиксации_ с помощью git + ssh. Клиент NPM по умолчанию поддерживает это.

Похоже, что номера 573, 633 и 639 связаны

Для контекста из документов NPM :

npm install <git remote url>:

Устанавливает пакет из размещенного поставщика git, клонируя его с помощью git. Сначала он пытается через https (git с github), а если это не удается, через ssh.

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

<protocol> - это одно из git , git+ssh , git+http , git+https или git+file . Если <commit-ish> не указано, используется master .

Также следует отметить, что <commit-ish> - это довольно широкий набор разрешаемых значений.

Объект commit или объект, который можно рекурсивно разыменовать на объект commit . Ниже приведены все фиксации: объект commit объект tag который указывает на объект commit объект tag который указывает на tag объект, который указывает на объект commit и т. Д.

Примечание. Эти установки удаленного URL-адреса git также должны быть гарантированы для работы как с общедоступными, так и с частными экземплярами сервера git с использованием ключей SSH для аутентификации сервера, а не только с GitHub / GitLab / и т. Вы можете представить себе сценарий, в котором компания использует собственный локальный сервер git для всех своих внутренне управляемых зависимостей (или даже частных репозиториев GitHub, доступных через SSH). На данный момент yarn не настроен для этих _ относительно распространенных_ вариантов использования.

Самый простой способ настроить репро-вариант - это попытаться установить пакет из частного репозитория GitHub с помощью Yarn.

Если вы укажете следующую исходную строку:

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

то он делает попытку клонировать заявленное хранилище через SSH, но терпит неудачу с «Отказано в доступе (ОткрытыйКлюче)» , потому что GitHub ожидает клиентов логина как git пользователя, и в этом случае пользователь локального учетной записи был использован по умолчанию .

Когда вы указываете git@ чтобы заставить git входить в систему как git в GitHub, он терпит неудачу, как обычно:

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

Итак, это почти работает, но не поддерживает указание имени пользователя. Если бы пользователь вашей локальной учетной записи назывался git , то это действительно было бы успешно.

Если вы добавите в файл ~/.ssh/config :

Host github.com
        User git

вы можете заставить все логины на github.com через SSH использовать пользователя git по умолчанию, и это позволяет yarn клонировать из частных репозиториев при использовании исходного формата ssh://github.com/<user>/<package> .

Для нас это категорический отказ, использование репозиториев, на которые ссылаются git (указывающие на наш локальный экземпляр gitlab EE), является сильной частью нашего рабочего процесса: cry:
Также это очень полезно для разветвления и указания на пакеты «перед слиянием и npm publish» (например, http-proxy ...)

@milosivanovic

Если вы добавите в файл ~ / .ssh / config следующее:

Но в моей конфигурации уже есть мои учетные данные ssh auth для github, поэтому я могу получить доступ к частным репозиториям. Этот обходной путь работает только для публичных репозиториев, верно?

@milosivanovic @ntucker на самом деле это сработало в моем конкретном случае; У меня не было файла конфигурации ssh для начала.

@kblcuk а, ну, @milosivanovic занимался другими проблемами и утверждал, что его обходной путь работал в этих случаях, поэтому я решил, что это проблема общих проблем с URL-адресами git.

@ntucker указанный обходной путь предназначен для частных репозиториев. Если у вас уже есть запись Host github.com в ~/.ssh/config , добавьте к этой записи User git , и yarn сможет клонировать, когда вы укажете исходную строку, такую ​​как ssh://github.com/<user>/<package> , т.е. без "git +" и без указания пользователя.

@milosivanovic Как github узнает мое имя пользователя, чтобы выполнить ssh auth?

@ntucker при общении через SSH GitHub ожидает, что вы https://help.github.com/articles/testing-your-ssh-connection/

Просто подумал упомянуть, потому что многие, вероятно, не знают об этой функции. Для GitHub вы также можете зависеть от URL-адреса архива, который отлично работает с yarn . Устанавливается тоже быстрее.

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

@milosivanovic, к сожалению, этот обходной путь не работает для наших внутренних URL-адресов в формате:
git+ssh://[email protected]:team-name/repo.git

Если вы измените исходное репо на формат ssh://source.com/team-name/repo.git ...

... тогда он будет работать для исходного ... но затем, конечно, все другие внутренние зависимости, на которые указывает первая внутренняя зависимость, нарушают его, поскольку все они находятся в этом формате.

Не просматривая и не меняя все URL-адреса во всех наших репозиториях и зависимостях в формате обходного пути (тогда нам приходится иметь дело с тем, что он не работает нормально в npm), мы тоже немного заблокированы в этом.

Как отметил @ 131 , это основной способ, которым команды используют npm внутри (о котором я знаю).

Кроме того, выглядит здорово!

@brokenalarms формат ssh://host.com/user/repo полностью обратно совместим с npm (при условии, что ожидаемый пользователь указан в файле конфигурации SSH), но тем не менее это справедливый момент.

Понятно .... Значит, они просто знают, какого пользователя тогда на основе ключа ssh?

@ntucker да

У меня была та же проблема, но мне помогло решение ntucker добавить User git в ~ / .ssh / config. По крайней мере, в среде разработки. Сейчас попробую развернуть на AWS EB :)

Могу подтвердить, что использование git+ssh://[email protected]:<org>/<repo> не работает в yarn и изменение на https://github.com:<org>/<repo> действительно работает, но это не сработает на нашем сервере CI, который все еще использует _NPM _.

Этот обходной путь мне помог:

1. изменил URL моего личного репозитория с

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

к

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

1. Добавлен пользовательский git в ~ / .ssh / config:

Host bitbucket.org
    User git

Host github.com
    User git

Кто-нибудь проверял, работают ли обходные пути с битбакетом?

@tgarbiak - да, я использую битбакет.

Используя BitBucket, я добавил это в свой ~ / .ssh / config:

Host stash.company.com
    port 7999
    User shawn

И использовал пряжу, чтобы добавить этот пакет:

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

Когда я запускаю npm install , он работает нормально, но когда я запускаю yarn install , я получаю эту ошибку:

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)

Да, как указывалось ранее, это временное решение работает.

Дело в том, что мы собираемся изменить это в каждом из наших 50+
зависимостей и требуя, чтобы каждый будущий пользователь принимал дополнительные
шаг подготовки их конфигурационного файла ssh для работы с пряжей или
существующая настройка npm, к сожалению, не подходит.

В среду, 12 октября 2016 г., 3:47 Свен Варкель [email protected] написал:

Этот обходной путь мне помог:

1. изменил URL-адрес моего личного репозитория с git + ssh: //git@host/user/private-repo.git
   к
   ssh: //host/user/private-repo.git
2. Добавлен пользовательский git в ~ / .ssh / config:
   ``
   Хост bitbucket.org
   Пользователь git

Хост github.com
Пользователь git

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/513#issuecomment -253180666 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AHC8CnUaBP_B_FL_AX1xL5FUrEWR-rnPks5qzLrTgaJpZM4KO4Cm
.

@diorman и всем, кто это читает: я настоятельно рекомендую вам не проверять токен github в свой файл package.json в системе управления версиями.

@jsdnxx спасибо, что указали на это. Я только что перешел в большой частный проект, в котором уже был токен в package.json для частных зависимостей. Буду следовать твоему совету. еще раз спасибо

Для веток обходной путь https://github.com/yarnpkg/yarn/issues/513#issuecomment -253059522 не работает, возможно, из-за кеширования. Я использую Yaska/keystone#yaska-build качестве имени пакета для установки, и он использует неправильную фиксацию, а при использовании https://github.com/Yaska/keystone/tarball/yaska-build прежнему используется неправильная фиксация. npm обрабатывает это правильно.

В связи с этим, если у меня есть локальная зависимость частного репо yarn link ed, yarn не следует даже проверять, находится ли эта зависимость в реестре npm, но в настоящее время yarn в этом случае не работает без каких-либо обходные пути, упомянутые в этой теме.

Предлагаемая конфигурация ~ / .ssh / config нарушает разрешение пакетов, поэтому не работает. Надеюсь, PR, который это исправляет, скоро будет объединен, иначе вернемся к старому доброму NPM.

Обходной путь для gitlab использует этот формат:

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

Также работает с частным репозиторием, используйте Gitlab Personal Access Token :

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

@Webysther - как сказал @jsdnxx :

Я настоятельно рекомендую вам не проверять токен github в файле package.json в системе управления версиями.

То же самое, очевидно, относится к GitLab или любым другим частным токенам.

Private Token только для параметра, более новая версия Gitlab может управлять токеном множественного доступа.
Я хотел бы использовать git + ssh в пряжи ...

Из Gitlab Docs:

Жетоны личного доступа

Вы можете сгенерировать личный токен доступа для каждого используемого вами приложения, которому нужен доступ к GitLab API.

Частный токен

Ваш личный токен используется для доступа к ресурсам приложения без аутентификации.

Я взглянул на код, и мне кажется, что однажды репозиторий git был
gotten, его хэш фиксации больше не проверяется, поэтому вы не можете отслеживать ветку.

Это правильная оценка, и если да, то относится ли она к другой
проблема?

Пт, 14 октября 2016 г., 6:52 Webysther Nunes [email protected]
написал:

Private Token предназначен только для параметров, более новая версия Gitlab может управлять
токен множественного доступа.
Я хотел бы использовать git + ssh в пряжи ...

Из Gitlab Docs:
Жетоны личного доступа

Вы можете сгенерировать личный токен доступа для каждого используемого вами приложения,
требуется доступ к GitLab API.
Частный токен

Ваш личный токен используется для доступа к ресурсам приложения без
аутентификация.

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/yarnpkg/yarn/issues/513#issuecomment -253709157 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AADWlhxxjS7Kl1wt_Wm6UG1Q_7X86D7oks5qzwqYgaJpZM4KO4Cm
.

@wmertens Нет, версия остается заблокированной внутри yarn.lock. Попробуйте yarn upgrade

@Webyst, увы, yarn upgrade не имеет значения. Он продолжает использовать старую фиксацию. Я должен отметить, что ветка была нажата принудительно, но я не думаю, что это имеет значение, потому что yarn должна найти фиксацию, соответствующую данному тегу, и установить ее, верно?

Я нашел обходной путь, заставляющий yarn получить правильную фиксацию:

Удалите пакет из ~/.yarn-cache а затем запустите yarn upgrade .

Он получит его снова, и все будет в порядке. Неправильно ли ожидать, что yarn upgrade проверит коммиты репозиториев git?

Я считаю правильным, что обновление пряжи должно проверять наличие новых коммитов git, однако это должно быть для каждой версии проекта, а не кэшироваться в домашнем каталоге пользователя. Но это тоже отдельная ошибка, я думаю

В наших проектах есть сотни записей package.json в форме
"[name]": "[email protected]:[team]/[project].git"
Обнаружена та же ошибка

Будет ли это исправлено PR №971?

@BryanCrotaz Нет, git+ssh://[email protected]:user/project.git#d6c5789 )

РЕДАКТИРОВАТЬ: как указано ниже @bdougherty , git+ssh://[email protected]/user/project.git#d6c5789 с / вместо : перед пользователем действительно работает.

+1

Мне удалось обойти эту проблему, изменив формат URL-адресов с

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

к

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

Оба формата действительны в npm, и единственная загвоздка в том, что все зависимости должны использовать этот формат.

@kittens Я думаю, что это ( git+ssh://git@host/org/repo.git ) теперь у меня работает?

пряжа : v0.16.1
узел : v6.9.1

Я не пробовал git+ssh://git<strong i="13">@host</strong>:org/repo.git но url.parse() , похоже, не полностью игнорирует : поэтому его, возможно, придется удалить:

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

Возможно, https://github.com/yarnpkg/yarn/pull/934 случайно исправил это?

@ Fishrock123 Я могу подтвердить, что установка пакета yarn v0.16.0 git + ssh, похоже, работает.
С v0.13.0 он постоянно терпел неудачу с error Couldn't find package "<package>" on the "npm" registry. для пакетов git + ssh.

@ Fishrock123 Подтверждено. Даже здесь это работает сейчас.

Да, # 934 должен был исправить это :)

Однако следующий формат работать не будет: git+ssh://git<strong i="6">@host</strong>:org/repo.git (с разделителем : )

Есть ли какая-нибудь информация о том, как скоро может появиться поддержка разделителя : ?

Я над чем-то работал, но у меня не было возможности сначала рассмотреть некоторые крайние случаи. Я постараюсь добраться до него на следующей неделе, если меня никто не опередит.

Что ж, у меня все еще есть проблема с этим, но, вероятно, немного другая. Я могу установить один пакет с yarn add git+ssh://[email protected]/group/foo.git#0.0.4 и он отлично работает. Затем я хочу установить еще один в тот же проект yarn add git+ssh://[email protected]/group/bar.git и внезапно получаю Couldn't find package "group-foo" on the "npm" registry.

Я использую версию 0.16. Могу я лучше создать новую проблему с этим?

Изменить: можно добавить, что yarn.lock выглядит нормально ...

"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: на самом деле может быть проблема в package.json, это выглядит после первой установки. Очевидно, он отказался от протокола, а в yarn.lock он сохранился. Я думаю, он просто не может его найти, поэтому вместо этого он смотрит в npm.

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

+100

Обновление до версии 0.16.1 и использование синтаксиса git+ssh://git@host/org/repo.git устранило проблему для меня (примечание: по-прежнему не будет работать с синтаксисом git+ssh://git<strong i="6">@host</strong>:org/repo.git )

Дело, безусловно, в том, чтобы поддерживать существующие файлы package.json, иначе миграция будет сложной и двойной запуск для тестирования невозможен.

Используя yarn 0.16.1 я смог использовать частный репозиторий с синтаксисом git + ssh. Кроме того, он правильно использовал пользователя git @.

@fermuch И вы можете запустить, например. yarn ls после такой установки? Как выглядит ваш package.json , URL частного репо такой же или как-то изменился?

@FredyC мой вывод 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]

Это было выполнено после удаления my-private-package из node_modules .
После yarn add я могу правильно видеть файлы внутри node_modules .

Выходы пряжи 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

Я не уверен, почему он дает 0.1.4 поскольку пакет не существует в реестре npm, а пакет github имеет версию 2.1.3 .

РЕДАКТИРОВАТЬ

Также стоит отметить, что это было добавлено в мои 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 Да, у меня там точно

У меня такая же проблема, но с общедоступным URL-адресом, а не по ssh.

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

Привет всем,

Я обнаружил, что проблема также связана с версией вашего узла.

Я использую формат "git + ssh: //[email protected]//.git #". Я занимаюсь разработкой для OSX и CentOS 7. Я обнаружил, что с последними версиями node 4 (v4.6.1) и node 6 (v6.9.1) yarn работает с этим форматом без проблем. Со старой версией node 4 (v4.4.5) он работает на OSX, но не на CentOS 7. В частности, когда yarn пытается загрузить репо, он просто зависает навсегда. Если вы столкнулись с той же проблемой, убедитесь, что вы используете последнюю версию узла 4 или 6.

Что касается kcormier, я пробовал как node 4.6.1 и node 6.9.1 и ни один из них не решает проблему пряжи, неспособной найти определенные тегированные версии репо через SSH.

Неудачный формат:

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

По-прежнему выдает ошибку, что не может найти версию, соответствующую тегу (отлично работает с npm).

Я считаю, что это нормально, если я заменю двоеточие после домена на косую черту. Странно, правда?

@alanhogan Я также заметил, что он отлично работает, если мы изменим двоеточие после домена на косую черту, но если пакет имеет другие зависимости git + ssh, вам придется изменить его в package.json устанавливаемой библиотеки / пакета . Другая проблема заключается в том, что даже если вы измените двоеточие на косую черту, при попытке сослаться на конкретную фиксацию или ветку будет срабатывать ошибка.

Я сам успешно ссылался на ветки и теги. Я использовал узел 6.9.1

Но да, рекурсивная проблема реальна, хотя и не так уж плохо, поскольку теоретически будут затронуты только наши собственные частные модули.

@alanhogan, да, я столкнулся с той же проблемой.

Приведенное выше исправление, похоже, не работает в моем случае. Я раздвоил официальный пакет Npm в своем репо, и когда я даю URL-адрес моего репо, даже с / вместо: yarn разрешает официальное репо. (официальный: https://github.com/TheLarkInn/angular2-template-loader, мой: https://github.com/Krisa/angular2-template-loader). Я не мог найти обходного пути (кроме использования Npm в настоящее время).

Для перехода от зависимости с версией к зависимости tarball требуется yarn cache clean прежде чем он фактически распакует tarball как новый node_module (Node v6 LTS и yarn v0.16.1).

армия разработчиков проголосовала за это, есть ли способ помочь?

@ f-sign работает над этим в нашей команде. Что-нибудь, с чем тебе нужна армия, Флавио?

Одной из существенных частей этой проблемы, по-видимому, является несоответствие package.json и yarn.lock, как описано @FredyC : package.json не содержит префикса git+ssh://git@ , который сохраняется в yarn.lock во время установки . Я думал, что пряжа предпочитает смотреть на файл yarn.lock, а не получать информацию о разрешении из package.json.

После редактирования package.json вручную и установки префикса все заработало.

@maybeec Эта проблема фактически уже решена в главной ветке ... https://github.com/yarnpkg/yarn/issues/1312#issuecomment -258230803

Молодцы, с нетерпением жду следующего релиза. Думаю, это исправит множество проблем.

Да, я совершенно сбит с толку, что мешает выпускать новые релизы. Этот примерно месяц сейчас? Я предполагаю, что это какая-то строгая политика Facebook или что ... 😢

1784 просит новый выпуск. Пожалуйста, оставьте отзыв "большой палец вверх"!

Моя проблема описывает проблему, которая похожа, хотя и не такая. Я немного просмотрел код и нашел эту интересную часть , которая фактически используется на каждом URL-адресе git:

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

Soooo .... Может ли кто-нибудь сказать мне, в чем причина удаления _git + _ для каждого URL- адреса

1816 вполне может это исправить - взгляните на изменения кода - он определенно решает проблему с двоеточием после домена

Проблема вроде бы исправлена ​​на yarn v0.17.0. Мне удалось получить один из моих частных репозиториев Github для конкретной версии.

Эта проблема исправлена? Я пытаюсь перенести свой проект с npm на yarn, но все еще сталкиваюсь с этой проблемой с

@viswanathamsantosh Кажется, работает на моей стороне

похоже, здесь это исправлено https://github.com/yarnpkg/yarn/pull/971 ! замена двоеточия (:) на косую черту (/) действительно сработала. : ')

Замена двоеточия на косую черту в моем случае не работает :( _git + ssh: //git@private..._ по- прежнему сокращается до _ ssh: //git@private..._

Да, у меня все еще есть эта проблема, даже с версией Yarn 0.17.2. Часть git+ удаляется, и я получаю:

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

Учитывая, что это работает для некоторых людей, я смущаюсь. Есть идеи, что мы делаем не так?

поместите это в ~ / .ssh / config

Host github.com
        User git

Да! Это исправило это для меня. Благодарю.

Было бы неплохо, если бы cleanUrl не запускались, поэтому вместо этого мы могли бы указать это прямо в URL-адресе. Для изменения файла конфигурации требуется изменение DevOps, которое в противном случае могло бы быть обработано системой контроля версий. Не знаете, какой мыслительный процесс стоял за этим ...?

Здесь та же проблема. URL-адреса частных репозиториев не работают как раньше (npm).

git + ssh: //[email protected] : ORG / repo.git должен работать, так как он должен быть совместим с npm на этапе миграции ...

@DominicBoettger После того, как вы добавили User git в свой ~/.ssh/config вы также захотите изменить это двоеточие на косую черту. По моему сегодняшнему опыту, пряжа еще не очень хорошо работает с толстой кишкой.

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

зависимости формы

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

не работают у меня с последней пряжей 017.2 . Ошибка:

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

Еще не тестировал обходные пути, но надеюсь, что yarn в конечном итоге будет поддерживать тот же синтаксис, что и NPM. Должна ли это быть новая проблема или все еще применимо к этой проблеме?

@sarus PR # 1816 исправит это

Пожалуйста, объедините PR № 1816 и опубликуйте новую версию 👍

Слияние? Кто то? НПМ ЗАБИРАЕТ МЕНЯ !! Пожалуйста, объедините и отпустите :(

Эта проблема остается в версии 0.18.0.

Вызов yarn install в чистом проекте без node_modules и файла yarn.lock работает. Повторный вызов сразу после этого приведет к ошибке «Не удалось разрешить имя хоста».

Я обнаружил, что удаление файла yarn.lock работает, поэтому я предполагаю, что либо что-то не так в файле блокировки, либо способ клонирования yarn при чтении из файла блокировки.

Надеюсь это поможет!

Именно эта проблема мешает многим разработчикам использовать пряжу.
Нам нужно серьезно отнестись к этому вопросу

@regou полностью согласен, чувак ... Это единственная причина, по которой я не могу использовать Yarn ...

Люди, вместо этого постоянного вопля, что никто не работает над этим, просто посмотрите на упомянутый PR № 1816, и вы увидите, что они пытаются объединить его ...

Пожалуйста, всем, у нас есть исправление для этого в # 1816, на которое мы с Флавио потратили около десяти дней.

Однако другой набор тестов терпит неудачу в зависимости от того, где они выполняются.

Пожалуйста, запустите тесты на своем компьютере и сообщите # 1816, какие результаты вы получили, и какая у вас версия ОС и узла.

Спасибо @FredyC и @BryanCrotaz за то, что

Исправлено через # 2384