Yarn: git+ssh install protocol is not used correctly

[sateffen]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

The problem is still the same as mentioned here and here.

Having a dependency

"git-dependency": "git+ssh://[email protected]:user/private.repo.git#awesometag"

leads to an install error message with multiple problems:

[1/4] Resolving packages...
? git-dependency@git+ssh://[email protected]:user/private
? git-dependency@git+ssh://[email protected]:user/private
error Command failed.
Exit code: 128
Command: git
Arguments: clone ssh://[email protected]:user/private.repo.git C:\...\Yarn\cache\.tmp\[hash]
Directory: C:\...\project
Output:
Cloning into 'C:\...\Yarn\cache\.tmp\[hash]'...
ssh: Could not resolve hostname privatgit.de:user: Name or service not known
fatal: Could not read from remote repository.

• The second and third line are missing the .repo part (the link should end with private.repo I guess)
• The seventh line stats, that the argument is missing the leading git+, which makes the repository unreachable (like told as error)

What is the expected behavior?

That yarn installs such private git dependencies just like NPM. NPM has no problems (v3 and v4 of NPM tested)

Please mention your node.js, yarn and operating system version.

• node v7.4.0
• npm v4.1.1
• yarn v0.19.1
• Windows 7 using git bash (windows cmd doesn't change the result)

[rally25rs]

In another issue report I found this workaround that helped me:

Try changing git+ssh://[email protected]:user/private to git+ssh://[email protected]/user/private

(a colon changes to a slash)
Hopefully that helps, until the URL parsing issue gets fixed.

[johnbwoodruff]

That workaround works until you're installing a repo that has its own dependency to another private one, but it uses a colon instead of a slash. Yarn then fails because it can't install that dependency. Supposedly version 0.19.0 fixes the colon issue, but I'm currently running yarn v0.19.1 and it is still failing for me.

[code-for-coffee]

@jbw91 is correct and our organization uses a lot of private repositories that may also import others. I'm able to verify this fails as of version 0.19.1. Maybe it is worth the time to go back and edit/test every package.json but that could lead to a lot of busy work. It would be great if Yarn could provide this functionality out of the box so our organization could consider it to replace using npm for the offline caching and such. My edited log is below:

yarn install v0.19.1
info No lockfile found.
[1/4] 🔍  Resolving packages...
error Command failed.
Exit code: 128
Command: git
Arguments: clone ssh://[email protected]:webapps/component.git /Users/codeforcoffee/Library/Caches/Yarn/.tmp/fca02e6debf948101fadfbf227bcab68
Directory: /Users/codeforcoffee/Documents/projects/webappsasa/ifc
Output:
Cloning into '/Users/codeforcoffee/Library/Caches/Yarn/.tmp/fca02e6debf948101fadfbf227bcab68'...
ssh: Could not resolve hostname git.mycompany.com:webapps: nodename nor servname provided, or not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
codeforcoffee at codeforcoffee-mbp in ~/Documents/projects/something on yarn-migration▲
$ yarn --version
0.19.1

System:

• Mac OS X 10.11.x
• node 6.9.2
• npm 3.10.9
• yarn 0.19.1

[sateffen]

Looks like yarn 0.21.3 fixes the problem. Can anyone else confirm that?

[code-for-coffee]

@sateffen from a very minor test I can confirm that Yarn will now install at least one level deep into private modules. So if you have public project a that includes private module b which depends on private module c, a will now be able to install b and c with no issue. Will test extensively when I am provided the time. I don't want to get _too_ excited yet, but it looks like this is resolved!

[johnbwoodruff]

This appears to work for me as well. Installing private modules that, themselves, reference other private modules, does now work.

[faassen]

While this works on Linux for me, it doesn't work on Windows with git bash. It tries to do a git clone without the "git+" bit (as reported originally on this issue) and then fails. This is yarn 0.21.3 on both platforms. (apparently 0.22 is released but has no windows installer nor a fedora package available?)

[faassen]

It actually does work on both Linux and Windows. I was mislead by a configuration that automatically used the git username to address the server, so that the correct key was sent. When I added an explicit "git@" in the git URL installation worked properly on both Linux as well as Windows.