ENOENT trying to require uuid.js when running yarn

[dikarel]

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

What is the current behavior?

On Windows 7 + Node.JS 6.9.1, running latest Yarn results in the following error message:

yarn install v0.17.9
info No lockfile found.
warning No license field
[1/4] Resolving packages...
error An unexpected error occurred: "ENOENT: no such file or directory, open 'D:\\apps\\npm\\node_modules\\yarn\\node_modules\\uuid\\uuid.js'".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\user\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Trace:

  Error: ENOENT: no such file or directory, open 'D:\apps\npm\node_modules\yarn\node_modules\uuid\uuid.js'
      at Error (native)
      at Object.fs.openSync (fs.js:640:18)
      at Object.fs.readFileSync (fs.js:508:33)
      at Object.Module._extensions..js (module.js:578:20)
      at Module.load (module.js:487:32)
      at tryModuleLoad (module.js:446:12)
      at Function.Module._load (module.js:438:3)
      at Module.require (module.js:497:17)
      at require (internal/module.js:20:19)
      at Object.<anonymous> (D:\apps\npm\node_modules\yarn\node_modules\request\lib\auth.js:4:12)

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

On Windows 7 with NodeJS and git-bash:

1. cd to an existing NodeJS project
2. Run the following command

npm update -g npm@latest
npm update -g yarn@latest
yarn

What is the expected behavior?

It should not throw an error

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

• Yarn version: 0.17.9
• Node version: 6.9.1
• Platform: win32 x64

[dikarel]

I looked at the yarn/node_modules/uuid directory. There isn't any uuid.js file in there.

There is, however, an index.js file. Is this what it was trying to require?

[culshaw]

@dikarel It looks like the folder structure of uuid was switched around. They also don't have a main entry in the package.json to aid pointing.

[richadr]

Might this be related to a recent update of https://github.com/request/request/ ?

I have the same issue. I install yarn using npm on my CI server. This would probably not occur if I install yarn using yarn, which for obvious reasons is impossible.

My first guess would be to update package.json and set request to ~2.79.0.

[richadr]

Also, I solved this on my CI server by running yarn cache clean.

[palmerj3]

I was hit by this issue on CI this morning too and it seems to be solved now

[Daniel15]

Please try installing Yarn via the Windows installer. Installing via npm often results in weird issues and we don't recommend it except in cases where there's no other choice.

[palmerj3]

Switching from NPM-based install to apt-get and then clearing the cache before installs on CI fixed this for me. FYI

[gitawego]

same prob in mac. it doesn't work even with yarn cache clean
I'm using 0.17.9
no problem at all in previous versions

[Daniel15]

@gitawego - How did you install Yarn? If you used npm, please try either Homebrew (if you have Homebrew) or the installation script instead:

curl -o- -L https://yarnpkg.com/install.sh | bash

[kidjp85]

Got the same issue even with older version (v0.16.0)

[cyyyu]

Got same issue using version 0.17.9 in macos.

I solved this by removing yarn which was installed with npm before, and reinstalled it with homebrew.

> sudo npm uninstall -g yarn
> brew install yarn

[blazzy]

My workaround was to downgrade to 0.17.8 on my CI server. Should have been locking down my yarn version anyway.

[Daniel15]

Should have been locking down my yarn version anyway.

Good idea :) We do suggest locking down the Yarn version in both the CircleCI and TravisCI docs: https://yarnpkg.com/en/docs/install-ci#circle-tab. On a CI system that uses Debian packages, you can use sudo apt-get install -y -qq yarn=0.17.9-1 to lock in a particular version, or if using the installation script you can pass a --version parameter.

[onemen]

uuid 3.0.1 that was published yesterday changed uuid.js with index.js

npm i uuid@3.0.0 will fix the issue

But if you run yarn upgrade again the bug will reappear.
yarn depend on "request": "^2.75.0"
request depend on "uuid": "^3.0.0"

The upgrade install uuid@3.0.1 again

[palmerj3]

Isn't changing a filename like this a breaking change?

[Daniel15]

See, this is why Yarn uses lockfiles, and why we advise against installing Yarn itself via npm. Gotta lock down your dependency versions to avoid unexpected breakages 😉

[navels]

I apologize for making this comment, I probably shouldn't. But venting might make me feel a little better.

I hate this whole node package ecosystem. There are so many layers of tooling now with so many opportunities for things to break. It is incredibly frustrating. We are just trying to get work done but there is so much churn from tooling issues. Makes me want to quit and go into alpaca farming.

[palmerj3]

Well in fairness yarn is still < 1.0 so I think they are working out a lot of issues right now. I tested yarn for weeks before using it on CI at work for production. But even so we hit this issue and I was able to get around it. I hear you though - the fatigue is real. Just don't expect any SLA's for < 1.0 and give the creators some credit because yarn is pretty freakin awesome.

[navels]

Yep, you're right. yarn is actually helping to solve some of the pain.

[jamiebuilds]

We should publish yarn with a npm-shrinkwrap.json so that people who choose to install with npm rather than one of the better system installers will at least get a more consistent experience.

[Daniel15]

Great idea @thejameskyle! I wasn't sure whether npm respects npm-shrinkwrap.json when installing global packages - Do you know if it does?

Maybe we should have a Yarn command to convert a Yarn lockfile into an npm shrinkwrap file?

[Daniel15]

(alternatively, could we convert the version ranges in package.json to exact version numbers when publishing to npm? I guess shrinkwrap essentially does the same thing)

[jamiebuilds]

Making them exact version numbers wouldn't fix the entire problem because that only locks the top-level dependencies.

I assume npm-shrinkwrap.json is respected in global installs, I would be very surprised if it was not.

Also, I'm not sure it's worth building a command to create a npm-shrinkwrap.json from a yarn.lock. It's my understanding that npm shrinkwrap will just use the current state of the node_modules directory, so I don't know what the value would be in having another yarn command to do it.

[navels]

We keep running into binary compatibility issues (e.g., installing node-sass) because developers have different versions of node/npm/yarn/etc installed and keeping everything in sync and up to date is impossible.

We build with gradle and there is a very nice plugin for running node tasks. The solution I've come up with to enforce version compatibility/consistency with the build across developer environments (linux/mac/windoze) is:

1. checked into source control:
   .yarn_install/package.json --> has yarn 0.17.9 as a single dev dependency
   .yarn_install/npm-shrinkwrap.json --> the resulting shrinkwrap, modified to target uuid 3.0.0 instead of 3.0.1
2. gradle uses the node plugin to npm install yarn in .yarn_install/
3. gradle uses the node plugin to yarn install everything else at the repo root using .yarn_install/node_modules/yarn/bin/yarn.js

I'm sure there is an appropriate meme for this.

[dbashford]

Any chance the version of uuid could be pinned and the NPM package updated? Seems like a quick short-term fix that'll get plenty of folks up and running again?

[Daniel15]

@dbashford I think request would need to pin it, as that's where the uuid dependency is coming from. Either that or we add a shrinkwrap file for Yarn (assuming it works as expected when installing global npm packages). Pull requests are appreciated in either case 😃

@thejameskyle - Would we check in the npm shrinkwrap file, or would it be built immediately before pushing to npm (eg. around here: https://github.com/yarnpkg/yarn/blob/master/circle.yml#L56)?

Making them exact version numbers wouldn't fix the entire problem because that only locks the top-level dependencies.

Good point!

[dbashford]

Ah yeah, brain fart on my end, I know better. My bad.

[tbranyen]

Urgh @Daniel15 I wish I had known before that it was not advised to install yarn via npm. We've been fighting with issues on an internal project that builds in Linux Jenkins and is developed on Macs and Linux boxes. Now that I know we can simply install through system package managers that will greatly help the bugs we've encountered!

Thank you!

[Daniel15]

I've got a pull request to update the site and clarify that installation of Yarn via npm is not ideal, I just need to tweak it a bit: yarnpkg/website#291 Sent from my phone.

…

On Dec 1, 2016 5:19 PM, "Tim Branyen" ***@***.***> wrote: Urgh @Daniel15 <https://github.com/Daniel15> I wish I had known before that it was not advised to install yarn via npm. We've been fighting with issues on an internal project that builds in Linux Jenkins and is developed on Macs and Linux boxes. Now that I know we can simply install through system package managers that will greatly help the bugs we've encountered! Thank you! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2072 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFnHdC6u_VSKusDH3ToRLbOWYRXHPXmks5rD3I3gaJpZM4K-7hl> .

[dbashford]

I just had the same thing happen with node-emoji which updated 15 minutes ago and also had a package.json update to main.

Error: ENOENT: no such file or directory, open '/pathto/.nvm/versions/node/v6.3.1/lib/node_modules/yarn/node_modules/node-emoji/index.js'
    at Error (native)
    at Object.fs.openSync (fs.js:640:18)
    at Object.fs.readFileSync (fs.js:508:33)
    at Object.Module._extensions..js (module.js:549:20)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/pathto/.nvm/versions/node/v6.3.1/lib/node_modules/yarn/lib/cli/commands/install.js:199:15)

[Daniel15]

I'm starting to suspect this is an issue with Roadrunner caching old paths, perhaps the cache isn't being cleared between releases. cc @kittens

@thejameskyle - Someone on Reddit pointed that shrinkwrap doesn't properly handle optional dependencies, so we probably can't use it if we have a transitive dependency on fsevents (for example): https://www.reddit.com/r/javascript/comments/5fyfqk/yarn_blog_lockfiles_should_be_committed_on_all/daodvyn/

[sebmck]

This is a known issue, I added a cache breaker in #1965 which should be in latest, if it's not then it'll be in the next release. The fix here is to remove the Yarn cache, one of the following commands should work:

# OSX
$ rm -rf ~/Library/Caches/Yarn

# Linux
$ rm -rf ~/.cache/yarn

# Windows
$ del %LOCALAPPDATA%/Yarn/cache

[wjordan]

Two things to note on this issue:

1. In old versions of yarn (0.16.1 in my case), the cache file is located at ~/.yarn/.roadrunner.json, so if you're running an old version of yarn try removing this file-path as well. (None of the above commands worked for this case).

2. The cache breaker in Add a cache breaker to roadrunner cache #1965 will not correctly solve this sequence of events (which was actually my use-case):

• npm install -g yarn@x.y.z - yarn version x.y.z is installed via npm
• yarn - entries populated in Roadrunner cache
• [one of the packages in yarn's dependency graph is released with a modified entry-point, and with a version still within the range specified by the package.json graph. For example, uuid@3.0.2 is released, which is still within the "uuid": "^3.0.0" range specified in request@2.79.1's package.json.]
• npm install -g yarn@x.y.z - yarn version x.y.z is re-installed, but this time with uuid@3.0.2 replacing uuid@3.0.1.
• yarn - this will break, because the old Roadrunner cache still persists, since the yarn version remained the same.

A more reliable cache-breaker fix will have to take the versions of all resolved dependencies into account, and not assume that yarn@x.y.z installed now will always have an identical set of package entry-points as yarn@x.y.z installed later.

[Daniel15]

Nice analysis, thanks @wjordan! Could you please create a separate issue for that, so your comment doesn't get lost?