[email protected] consistently 404s on private packages

[spencer-brown]

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

bug

What is the current behavior?
[email protected] fails to install private packages on every run of yarn across several different projects/lockfiles, with a 404.

eg

If the current behavior is a bug, please provide the steps to reproduce.

presumably, run yarn with [email protected] installed against any yarn.lock that includes private packages.

What is the expected behavior?

[email protected] installs private packages.

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

node: 6.9.1
yarn: 0.27.3
OS: [email protected], ubuntu 14.04.5 LTS

[bestander]

Thanks, looks like this one slipped.
I am thinking of rolling back 0.27.3 to RC

[wearhere]

Thanks for the quick response @bestander. Curious about "looks like this one slipped"—does Yarn not have tests for private module support? That's a huge part of our (and I would assume many folks') use of npm.

[bestander]

I think we have never set up e2e tests for private modules.
Would you want to help us out, set up an account and write a test?
We can take care of the billing

[Daniel15]

We can take care of the billing

We don't necessarily need something like npm enterprise, we could just have some simple server that we host ourselves

[robinst]

@bestander Looks like the Debian archive still has 0.27.3, is it possible to roll that back as well?: http://dl.yarnpkg.com/debian/dists/stable/main/binary-all/Packages

[bestander]

I think it is more work than fix the 2 issues we have, we'll fix them ASAP

[Daniel15]

@robinst No need to roll it back, you can install a specific version like this:

sudo apt-get install yarn=0.24.6-1

To keep it at that version (and never install a newer version), you can use mark the package as "held back":

sudo apt-mark hold yarn

This will keep 0.24.6 installed even if you run apt-get upgrade.

You then do sudo apt-mark unhold yarn && sudo apt-get upgrade to get the newer version at some point in the future.

[robinst]

@Daniel15 Thanks. Yeah, that's what I'm doing as a workaround (except with 0.24.6-1). The apt-get install is in a Docker image, so it would be nicer if we could keep using stable instead.

[bestander]

@spencer-brown can you confirm in what version it worked for you?
Have you tried 0.26?

[arcanis]

0.26 is also affected, please use 0.25.4 instead. The commit that introduced the bug is 3382071.

[bestander]

Commented on a change that probably introduced the break.
We need to start the fix with proper tests in place #3231 (comment)

[bestander]

@spencer-brown, can you confirm if the issue is still there in 0.27.4?

[scottyeck]

@bestander Please ignore if I'm being another cook in the kitchen, but I can confirm the issue in 0.27.4...

[bestander]

@scottyeck, you are most certainly welcome.
Can you help us out a bit and check in which releases it worked.

These are the recent releases

     '0.24.4': '2017-05-12T17:30:22.376Z',
     '0.25.1': '2017-05-12T19:22:43.139Z',
     '0.24.5': '2017-05-15T18:52:11.047Z',
     '0.25.2': '2017-05-15T18:54:13.175Z',
     '0.24.6': '2017-05-23T20:05:58.254Z',
     '0.25.3': '2017-05-23T20:06:55.232Z',
     '0.25.4': '2017-06-01T12:30:04.516Z',
     '0.26.0': '2017-06-06T13:16:17.273Z',
     '0.26.1': '2017-06-07T14:12:38.092Z',
     '0.27.0': '2017-06-23T13:24:49.267Z',
     '0.27.1': '2017-06-27T10:02:40.390Z',
     '0.27.2': '2017-06-29T02:08:55.267Z',
     '0.27.3': '2017-06-29T20:45:10.584Z',
     '0.27.4': '2017-06-30T20:23:36.901Z' },

[scottyeck]

I just rolled us back to 0.24.6, which was our last usage without failure. I'll try the incremental upgrades over the next few moments and report back.

[scottyeck]

Reporting back...

'0.24.4' - (did not test)
'0.25.1' - (did not test)
'0.24.5' - (did not test)
'0.25.2' - (did not test)
'0.24.6' - :)
'0.25.3' - :)
'0.25.4' - :)
'0.26.0' - (version not found?)
'0.26.1' - :)
'0.27.0' - :)
'0.27.1' - :)
'0.27.2' - :)
'0.27.3' - :)
'0.27.4' - :( <- only failure

[arcanis]

That's really weird ... I just checked the 0.27.4 with my private pkg (@arcanis/private-pkg), and it works fine o0

[arcanis]

I managed to reproduce the issue! For some reason, yarn add <pkg-name> manages to fetch the package when the cache is empty, but yarn install doesn't.

$> yarn add @arcanis/private-pkg     # ok
$> yarn cache clean
$> yarn install                      # ko

[bestander]

0.27.5 is coming with a patch in 20 minutes

[bestander]

@scottyeck, can you test 0.27.5, it is available?

[scottyeck]

@bestander Just a moment.

[scottyeck]

0.27.5 is available and OK on my end.

[BYK]

@bestander @arcanis I think we're good to close this one?

[arcanis]

Not until we merge #3774 into master - right now it has only been cherry-picked into 0.27. Currently have a few things on my plate, so it will take a few days.

[plmrry]

In case this helps someone:

If you are copying an auth token from a registry.npmjs.org URL within .npmrc, make sure to include the protocol (e.g. http or https) in the URL.

Yarn >=1.0.0 was breaking our CI builds because #3987 prevents the use of protocol-relative URLs (e.g. //registry.npmjs.org/). The URL written to .npmrc by npm login is procotol-relative, which prevents Yarn from matching registry URLs to pathname URLs.

[ELD]

We found that adding always-auth=true to the .npmrc helped out too.

[mweststrate]

I run into a similar issue. For future readers, removing the private repository mapping from .npmrc fixed it for me (simply comment out a line that looks like)

@mycompany:registry=https://registry.npmjs.org/

[GeoffreyPlitt]

None of these solutions worked for me.

[elyobo]

Ongoing inconsistent occurrences of this for us too (version 1.3.2)

[sundowndev]

Same issue with yarn 1.22.4

My .npmrc

registry=https://registry.npmjs.org/
//registry.npmjs.org/:_authToken=${NPM_TOKEN}