Yarn installation fails if Yarn policies are in use

[gggritso]

Orb version:

5.0.0

What happened:

I'm using Yarn policies (e.g., yarn policy set-version 1.22.11) to bundle Yarn with my app. .yarnrc looks like this:

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


lastUpdateCheck 1579039968308
yarn-path ".yarn/releases/yarn-1.22.11.js"

I'm trying to use this orb to install Node and Yarn, like so:

- node/install:
    install-yarn: true

This downloads the latest stable version of Yarn, which is 1.22.17 at the time of writing. Unfortunately, the installation process fails at the end with this error:

Verifying YARN install
Something went wrong; the specified version of Yarn could not be installed

This happens because after the Yarn installation is complete (1.22.17 is successfully installed) yarn --version returns 1.22.11, which is the version specified in .yarnrc. This mismatch causes the process to exit.

Expected behavior:

I'm not sure, to be honest! A few options are possible:

• if the Yarn installation process somehow respected the contents of .yarnrc that would help
• if it was possible to skip the version check, that might be good
• if the installation check was smarter and checked policies that would help as well

I could hard-code the Yarn version in the task config, but that defeats the purpose of using .yarnrc. I could also somehow parse .yarnrc myself and extract the version, but that's the yarn executable's job. Any advice here would be appreciated!

[Jaryt]

Thanks! Will take a look into this and get back to you shortly 👍

[techpeace]

This was reported in the community forum, and I've also been running into it. A user there reported that they tracked it down to a certificate check.

[Jaryt]

Hi! After looking into this further, I'm wondering if installing yarn here is redundant as it looks like the .yarn/releases folder is allows yarn to be managed via source control. What behavior do you experience when you remove the install-yarn parameter?

[gggritso]

@Jaryt I agree, it would be better to use the executable in .yarn/releases, but there's no clean mechanism to do so! The behaviour we experience is that the yarn command fails, because there isn't a yarn command, and we use yarn to run tasks like yarn test.

We alias .yarn/releases/yarn-1.22.11.js to yarn to overcome this. It's fine, but a little gross because we have to either hard-code the Yarn version in our CircleCI config or we have to iterate through the contents of .yarn/releases to find the file, and create an alias.

The first option is a little frustrating because we'd have to update the file any time we upgrade Yarn. The second version works better, but is a little messy. Mostly, it's just surprising that the installation fully fails if Yarn policies are used.

[Jaryt]

@gggritso I see! Thanks for that description of the issue. Seems like the way forward would be to automatically alias (todo: confirm that is what yarn is actually doing in the set-version script) to the yarn-path included in either of the yarnrc files. Will work on getting this in this week 👍

[gggritso]

@Jaryt that's great, thank you!

[Jaryt]

Hi @gggritso Sorry for the delay here, had my hands full with some other tasks. I'm implementing the fix right now, and the solution actually quite simple. Since the yarn --version command is being called while your project is the working directory, it's picking up the version from the yarn path locally. So, the only change necessary is to change the working directory to home so that it uses the yarn --version from the actual yarn binary.

[Jaryt]

Confirmed fixed 😄

Will be in next fix release!

[gggritso]

@Jaryt thank you very much for fixing this!