Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use shortand for gitlab dependencies #2774

Open
ramiel opened this issue Feb 24, 2017 · 11 comments · May be fixed by #7605
Open

Use shortand for gitlab dependencies #2774

ramiel opened this issue Feb 24, 2017 · 11 comments · May be fixed by #7605

Comments

@ramiel
Copy link

ramiel commented Feb 24, 2017

What is the current behavior?
yarn add "gitlab:mygitlabuser/myproject"

gives an error

What is the expected behavior?

Should behave the same as
npm install -S "gitlab:mygitlabuser/myproject"

With npm this is a valid dependency also in package.json, while it doesn't work with yarn. This is actually a simple shorthand for a complete git url and work the same for bitbucket and gist

Please mention your node.js, yarn and operating system version.
node v7.6.0 on Kde Neon (linux 4.4.0-64-generic)

@Daniel15
Copy link
Member

Feel free to send a pull request adding this if you like.

@ramiel
Copy link
Author

ramiel commented Feb 27, 2017

If I have time it'll be a pleasure!

@ramiel
Copy link
Author

ramiel commented Feb 27, 2017

I investigated and discovered that yarn is totally capable to resolve that kind of dependency references (i.e. gitlab:mygitlabuser/myproject). The problem is, it is not able to download private packages. On the opposite npm is capable of doing it. The problem, I think, is that npm resolves the shorthand into the url

git+ssh://[email protected]/mygitlabuser/myproject.git#<ref>

while yarn transforms it into

 https://gitlab.com/mygitlabuser/myproject.git

and so, it encounters authentication problems because it isn't using ssh.
The yarn codebase is large and I need more time to understand why and where it differs like this from npm. If somebody can have a look at this or give me an hint, it should be appreciated.

@ramiel
Copy link
Author

ramiel commented Feb 27, 2017

Or maybe that url is only used to get back the ref from the repository. In any case npm does something different to retrieve it.

@hx-markterry
Copy link

hx-markterry commented Feb 28, 2017

This line here tries to check to see if accessing a private repo would work over HTTP:

if (await this.hasHTTPCapability(httpUrl)) {

it always seems to pass, if you change it to return false, packages will be installed via git successfully, but will be slower.

I wonder if a "prefer git" CLI option could be used here, or have a better way of checking if a repo is available over HTTP.

Is defaulting shortened git urls to use git by default rather than HTTP a more expected result (although slower)?

@ramiel
Copy link
Author

ramiel commented Feb 28, 2017

Npm checks http first,for what I can see in the logs,than it fallbacks to git+ssh

@SunnyTam
Copy link

suffering same problem

@thedumbterminal
Copy link
Contributor

Working on a PR to solve this issue: #2992

@hx-markterry
Copy link

hx-markterry commented Apr 10, 2017

Version 0.23 fixes URLs in the format of github:somecompany/somename.git#v1.2.3 but not URLs in the format of: github:somecompany/somename#v1.2.3.

Seems like a problem with the regex at:

https://github.com/yarnpkg/yarn/blob/master/src/util/git.js#L62

@thedumbterminal
Copy link
Contributor

New PR to allow more git URL formats: #3445

@BYK
Copy link
Member

BYK commented Oct 16, 2017

The code around this functionality is quite a lot cleaner now so if anyone wants to give a shot at submitting a PR, now is a great time :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants