yarn crashes after update to latest version

[smelukov]

I just updated yarn to latest version (0.21.3)

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

Report a bug

What is the current behavior?

Crashes with error:

/usr/local/lib/node_modules/yarn/bin/yarn.js:61
      throw err;
      ^

Error: ENOENT: no such file or directory, open '/usr/local/lib/node_modules/yarn/node_modules/end-of-stream/node_modules/once/once.js'
    at Object.fs.openSync (fs.js:558:18)
    at Object.fs.readFileSync (fs.js:468:33)
    at Object.Module._extensions..js (module.js:579:20)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/usr/local/lib/node_modules/yarn/node_modules/end-of-stream/index.js:1:74)
    at Module._compile (module.js:571:32)

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

npm i -g yarn
yarn

What is the expected behavior?

I just want to yarn is working ;)

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

Node: 7.4.0
NPM: 4.0.5
OS: MacOS 10.12.3

[Daniel15]

Try installing Yarn using Homebrew rather than npm and see if that helps.

[smelukov]

@Daniel15 it works now. Thanks!

But I was installing yarn through npm before this update and it worked fine.
Is this expected behavior that yarn is not working through npm now?

[Pharylon]

Same thing happened to me on Windows. I decided to try and upgrade to see if Issue 1059 was fixed, and instead everything broke. Installing using the MSI fixed it.

Also, on a side note, Issue 1059 still isn't resolved, even though it's been marked Closed for like four months.

[Daniel15]

Is this expected behavior that yarn is not working through npm now?

There's sometimes weirdness with installing via npm that doesn't happen with the other installation methods.

Also, on a side note, Issue 1059 still isn't resolved, even though it's been marked Closed for like four months.

Perhaps there's a separate issue that just looks related to the original issue?

[Pharylon]

@Daniel15 I know this isn't the place to discuss it, but it's literally exactly that issue. On windows, installing with yarn causes errors to be printed to the console for modules like fsevents which aren't Windows compatible, and that causes my CI server to think something went wrong and marks the build failed.

[Daniel15]

, installing with yarn causes errors to be printed to the console for modules like fsevents which aren't Windows compatible

What's the exit code though? Yarn and npm both output to the console when an incompatible module like fsevents is an optional dependency of whatever you're installing. However, the exit code should still be 0, so it shouldn't be marked as a failure by your CI server.

[thymikee]

Huh, it happens for me when fresh installing with brew (only after I've removed old versions and ran brew cleanup -s), but works with npm 🤷‍♂️

/usr/local/Cellar/yarn/0.21.3/libexec/lib/node_modules/yarn/bin/yarn.js:64
      throw err;
      ^

Error: ENOENT: no such file or directory, open '/usr/local/Cellar/yarn/0.21.3/libexec/lib/node_modules/yarn/node_modules/end-of-stream/node_modules/once/once.js'

For some reason it tries to find once in end-of-stream's node modules instead in yarn deps (where once is present).
Node v7.5

[ProdigySim]

I managed to get this error as well. Npm3 is known to have non-deterministic locations for sub-dependencies, but I don't understand why yarn is dependent on these locations.

npm 3.9.0, node v4.5.0. I'm using NVM as well.

Also note, if I simply go to ~/.nvm/versions/v4.5.0/lib/node_modules/yarn and just run node -e 'console.log(require("end-of-stream"))' it works just fine.

[ProdigySim]

Workaround / fix: Delete .roadrunner.json from your Yarn Cache directory.

On OSX El Capitan: ~/Library/Caches/Yarn/.roadrunner.json
[untested] on Windows: %LOCALAPPDATA%/Yarn/.roadrunner.json
[untested] on linux: ~/.cache/yarn/.roadrunner.json

Hopefully this works for someone other than me :)

Details

I ran through this with node-inspector/node-debug, and placed breakpoints around attempts to require('once') and stepped through the code. It is only required once, and the Module._pathCache object already has an entry describing where to find the once library.

Module._pathCache should be empty when node boots, but it looks like yarn.js loads roadrunner, which overwrites Module._pathCache andModule._realPathCache with a cached version.

By manually inspecting the .roadrunner.json file, I could multiple entries for once that pointed to the wrong location.

"{\"request\":\"once\",\"paths\":[...]}":
   "/Users/username/.nvm/versions/v4.5.0/lib/node_modules/yarn/node_modules/end-of-stream/node_modules/once/once.js",

NPM3 dependency install trees are known to be non-deterministic. So, if you're installing yarn with npm these paths might get jumbled, and then the roadrunner cache becomes invalid. As to why the paths part of the cacheKey for the _pathCache wasn't enough to protect against this, I don't know.

It might be a good idea to add a safety feature or command flag to yarn that clears the roadrunner cache as it loads. I do wonder if #1074 is the same issue as well.

[sirlancelot]

@ProdigySim Thanks for pointing that out. I deleted _just_ the file: ~\AppData\Local\Yarn\cache\.roadrunner.json (Windows) and it runs fine.

I'm installing and using Yarn through NPM. It's the easiest and best method IMO.

[fdesjardins]

@ProdigySim Thanks! That worked for me on Linux.

I also always install Yarn via NPM and agree it's generally the easiest way.

[spicydonuts]

I also just started running into this. I installed yarn via homebrew but haven't updated in a few days. When I first ran into it I removed my node_modules and ran yarn again which worked fine, but then it kept breaking again after a few hours. We'll see if deleting .roadrunner.json lasts longer.

[therebelrobot]

The deleting of roadrunner worked for me, installed via NPM in NVM on OS X El Capitan. Thanks @ProdigySim!

[Daniel15]

This should be fixed now that we're removing Roadrunner.