-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Yarn writes registry.yarnpkg.com to lockfile when private scoped packages is from registry.npmjs.org #4157
Comments
Bump Anyone else seeing this behavior? No reply from anyone so far :( |
Should be fixable by implementing #3330 |
@Haroenv Yep... should be fixed by #3330 but that is going to break backwards compatibility and based on discussion in that thread that won't be resolved for some time (need RFC, general agreement, roll out of a major release). A simpler fix here AFAICT would involve disabling yarns predisposition to replace |
+1 I am finding this issue as well. have you gotten any work around to effectively work for you @stieg ? |
Honestly we have moved back to npm for now since it works. My work around
was a script that would modify the lock file with the correct path for
those packages.
On Sun, Sep 10, 2017, 18:16 Karl Ringrose ***@***.***> wrote:
I am finding this issue as well. have you gotten any work around to
effectively work for you @stieg <https://github.com/stieg> ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4157 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIozzeWZwvPAnbbh5r5GRugYWc6voD3ks5shLQJgaJpZM4O1Ps2>
.
--
- Andrew S.
|
I was about to do this, though my work around now is to just delete the yarn.lock file, and have hard versions set within pkg for build. We will most likely migrate to npm@5 if this issue is not resolved. |
This bug has been causing a lot of inconvenience for a long time. |
I'm sorry that you are having issues with this. I'm trying to see exactly what is wrong since Yarn's registry is just a CDN that needs to bypass everything so it should work with scoped packages properly. In fact, I can locally use scoped packages such as Can anyone provide me some step-by-step instructions to replicate the issue locally and then we can start working on a solution? This may simply be a bug when you say your default registry should be NPM and Yarn incorrectly replaces it with its default registry. |
@BYK I would start by re-reading the first comment on this thread to get an understanding of the behavioural problem. The maybe not so clear subtext is that since Yarn is re-writing the lock file paths to |
@stieg - I've read the initial comment and have understood the issue. I'm just trying to understand how it happens since it doesn't happen to scoped packages for instance which require authentication. I'm also investigating why the rewriting happens and if it is something that should happen in the presence of an explicit That's why I was curious about new and precise step-by-step instructions. Also we've made a bunch of improvements about detecting when to send aithentication headers and when not to on the latest master. Would you be willing to test one of the latest nightlies and see if they already solve the issue (not the rewrite but the actual, fetching the package issue). Nightlies can be found here: https://yarnpkg.com/en/docs/nightly |
I see @BYK; you need a way to reproduce this (as you mentioned in your first comment). When I first encountered this issue I was running yarn v0.28.4 (as noted in the first comment). It seems that I can only hit this issue with that version of yarn and lower. On the current 1.0.1 release things are broken in a different way for me (described below). Alas here are the requested steps to reproduce: With yarn v0.28.4
That is the failure.
With yarn v1.0.1
I can work around the problem by doing the following:
This will cause the package to install successfully. But then I will get stuck with a diffent problem when I hit step 10 (yarn doesn't seem to be authenticating using the data from .npmrc). So I'm dead in the water :(. This behavior is the same with both 1.0.1 and the latest nightly. Perhaps I am just doing something so very wrong that yarn is confused and thus not working? Tips appreciated :). |
@stieg - I think we are onto something here :) I don't think it is what you are doing. 1.0.1 had still bugs around which would cause this. 1.0.2 is around the corner and you can test it with the nightlies https://yarnpkg.com/en/docs/nightly I'm quite confident that the error will go away but I would appreciate your confirmation if you have the time. |
Any links to issues you are referring to? I tried the nightly yesterday to no avail so if there is a particular one you wish for me to check out I will be happy to do so. |
I'm still seeing this on 1.0.2, but got it to work again by removing |
@simonkberg thanks a lot for sharing these details. What I hear is |
@BYK yep, in 1.0.2 that line still causes me to get 404 errors for our private scoped packages. It automatically gets added to your |
@simonkberg I've tried to reproduce this issue with the My suggestion would be to either update the lock file manually or remove it and regenerate with the new setting. |
I just tried to reproduce and can confirm that 1.0.2 seems to resolve this issue. Thanks @BYK |
Weird, I could reproduce this reliably on multiple of our repos before but I'm not able to anymore. I'll try to update our base/ci images to yarn 1.1.0 and if we encounter anymore authentication problems I'll report back. Thanks @BYK |
I have this issue with 1.1.0
did fix the issue, no idea why. With and without that setting, yarn was able to access the package metadata,
But with it, it failed with downloading the tgz file. BTW, it would be nice if --verbose will also print info about if credentials sent with the request |
Opened a PR - #5162 feedback (or even QA) welcome. |
@stieg and others. At this point in time yarn still writes yarnpkg.com as registry to the lock files. But the auth issue has been fixed. That is it should be possible to install private npm pkgs in CI by authenticating against npm. If this is still an issue for you, please reopen. |
I see this issue with yarn 1.7.0 |
This is still an issue with yarn 1.22.10. If I do
In
Which in turn fails in CI during
My project level
|
Do you want to request a feature or report a bug?
Bug
What is the current behavior?
I have something like the following in my ~/.npmrc file:
This is necessary so I can login to my private repo and get the packages I need to build locally.
When I add a new package like @mycompany/foo I would expect an entry in the
yarn.lock
file to look something like this:Yeah... not so much. Instead it looks like this:
Uncool yarn. This causes my CI to break because it will try and dig up the packages at
registry.yarnpkg.com
. Since this is a private registry the login will fail (since the registry is hosted on registry.npmjs.org) and thus it will cause other systems to fail to install packages.Here is how to reproduce:
mycompany
with your own scope, and set a valid auth token of course), and runyarn add <your scoped package>
. You can do this by doingnpm login --registry=https://registry.npmjs.org --scope=@<your scope name>
. I would use yarn login but that doesn't work :(yarn add
You will see that the URL gets changed in the lock file.
Please mention your node.js, yarn and operating system version.
node: 8.2.1
yarn: 0.28.4
OS: Fedora 26
The text was updated successfully, but these errors were encountered: