Would be nice to have an official yarn step.
Yarn is commonly used as a npm replacement. It’s also popular with react native mobile apps.
Makes sense, especially that we have a step for NPM - thanks for the #feature-request @bootstraponline !
Actually there’s already an “unofficial” step for this, available in the StepLib right now: https://github.com/jonoirwinrsa/steps-yarn
Yeah, I’m not sure I want to pull in a shell script from a random GitHub account. I think having the logic in golang, especially for installing, may be a bit more reliable.
It does work though.
Thanks for the info @bootstraponline , we’ll keep this #feature-request then, for an official step
https://github.com/jonoirwinrsa/steps-yarn also only works for Ubuntu when installing yarn (apt-get). I need yarn on macOS.
I think an official step would support yarn correctly on both Linux and macOS.
Got it, added it to our internal tracker, but can’t promise anything / set an ETA yet
In the meantime, if you have some time, send a PR to the currently available (3rd party) Yarn step, I’m sure they’d be happy
Actually I just checked that step and it declares yarn as a dependency so the CLI should auto install it with brew.
Are you sure that you tested it on MacOS @bootstraponline ?
1. Set a command in **The yarn command to run** input.
If you leave the input blank, the Step will simply install your dependencies. You can find the other available command in [yarn's documentation](https://yarnpkg.com/lang/en/docs/cli/).
1. Set the arguments in the **Arguments for running yarn commands** input.
You can specify multiple arguments. Check out the available arguments for each command in yarn's documentation.
You can also cache the contents of the node_modules directory by setting the **Cache node_modules** input to `yes`.
### Troubleshooting
If the Step fails, run it again with verbose logging enabled. To do so, set the **Enable verbose logging** input to `yes`. Doing so allows yarn to output more information about the command you ran.
Make sure your commands and arguments are correct, and that your packages are correctly defined in the `package.json` file.
### Useful links
[Getting started with React Native apps](https://devcenter.bitrise.io/getting-started/getting-started-with-react-native-apps/)
[Running Detox tests on Bitrise](https://devcenter.bitrise.io/testing/running-detox-tests-on-bitrise/)
It works on macOS, however I though that was because the osx-box-bootstrap already has yarn installed. I didn’t notice it’s auto installing via brew in step.yml, I only briefly looked at the apt-get logic.
Sounds like it already has the required features.
Indeed, the step seems to be right, when yarn is not installed the CLI will install it for it (using brew - https://github.com/jonoirwinrsa/steps-yarn/blob/master/step.yml#L21 )
But if yarn is already installed then the CLI will not install it. Unfortunately the current deps definition only allows to define the presence (and install method) of a given tool, it’s not possible right now to define any version for the tool. So with a deps def like the step has the CLI will only ensure that yarn is available, it’ll never attempt to update it / it’ll skip it entirely if it’s already installed.
I’m using the latest stable yarn so that is a good match for my needs.
Ideally we’d match the same yarn version used to create yarnfile.lock Buddybuild raised an issue upstream and it looks like this feature has been added.
opened 07:53PM - 06 Mar 17 UTC
closed 09:17PM - 12 May 17 UTC
needs-discussion
triaged
Referring to : https://github.com/yarnpkg/yarn/pull/2779
@bestander - I’d lik… e to add some more context to this and get this reconsidered.
This change will be valuable for any team that uses a CI that does any kind of inference. The CI service can guarantee the correct version of yarn is used for the build.
Without this it places a burden of yarn version management onto teams that use CI. Users often forget to update CI to match their local environment, and spin frustrated because the error messages for incompatible versions can be very cryptic.
For a CI service like ours, that ends up burning a lot of support time too.
This has happened twice in the last two weeks now:
Originally in buddybuild, we were always updating to the latest yarn version for a build. About a week and a half ago a new version of yarn came out that prompted for user input in a particular circumstance. That caused builds to hang.
These hangs were affecting customers who hasn’t yet upgraded yarn locally.
When that happened we rolled back and pinned to the previous stable version 0.18.1.
It now looks like that version of yarn isn’t capable of correctly installing yarn.locks generated with the latest stable version.
We had a flurry of support requests the last few days with customers confused by yarn errors like these:
```error An unexpected error occurred: “ENOENT: no such file or directory, open ‘/usr/local/lib/node_modules/yarn/node_modules/har-validator/lib/index.js’”.```
The latest yarn successfully installs. Between these versions the ‘yarn lockfile’ version wasn’t bumped.
To me, it seems there are two solutions:
1) Bake the yarn version into the yarn.lock
2) Require the user to manually update their CI
Among the two big iOS package managers cocoapods & carthage, cocoapods takes the approach of baking the cocoapods version into the Podfile.lock, whereas carthage doesn’t put its version into Cartfile.resolved.
Within buddybuild cocoapods has 10x the usage of carthage, however carthage has 5x rate of failures. Many of these are due to the wrong version.
Baking in the version to yarn.lock will also help teams who want to make sure they’re in sync with yarn versions. Merge conflicts will only occur with teams with folks using different versions - and should be simple to resolve. Anecdotally, I’ve never heard of a similar complaint with this behaviour in cocoapods.
If the conflicts becomes a problem, a setting to disable this behaviour would solve that.
As the carthage case shows, requiring the user to manually update their CI will lead to more fragility.
