Yarn version: 1.1.0
Node version: 6.9.4
Platform: linux arm Raspbian 64 bits (Raspberry pi 3)
When I run the command yarn install --production
with a yarn.lock file I have a random error
Error: https://registry.yarnpkg.com/postcss-merge-idents/-/postcss-merge-idents-2.1.7.tgz: ENOENT: no such file or directory, open '/home/pi/.cache/yarn/v1/npm-postcss-merge-idents-2.1.7-4c5530313c08e1d5b3bbf3d2bbc747e278eea270/README.md'
Not always on the same package, it's look like an old bug: https://github.com/yarnpkg/yarn/issues/2629
I manage to complete the installation with the command with yarn install --production --network-concurrency 1
.
I try to clear the cache but the problem was still present.
The problem may be related to very bad network connection, the installation stopped not much after seeing a warning about a failed connection.
Hopefully not noise: I see a similar symptom on 1.0.2, and I wonder if it could be the same cause:
error An unexpected error occurred: "ENOENT: no such file or directory, scandir '/path/to/node_modules/something'"
scandir
, lstat
, as well as open
.yarn link
'd modules.$ yarn install --mutex file:/tmp/.yarn-mutex
$ yarn install --mutex file:/tmp/.yarn-mutex --network-concurrency 1
$ yarn install --network-concurrency 1
$ yarn upgrade some-dep --mutex file:/tmp/.yarn-mutex
$ yarn upgrade some-dep --mutex file:/tmp/.yarn-mutex --network-concurrency 1
$ yarn upgrade some-dep --network-concurrency 1
My system specs:
Yarn version: 1.0.2
Node version: 8.4.0
Platform: macOS Sierra (10.12.4)
My installed yarn version: 1.2.1
OS Version: Windows 10 (Latest Fall Creators Update)
I have often a similar problem, when I try to use the command electron-forge init --template=angular2
. electron-forge uses yarn internally, when it is installed.
It feels to me, if there is something like a race condition or the like. Sometimes, there are no errors at all. And another time, I get very much errors of that kind after several trials.
I wrote a detailed error report there: https://github.com/electron-userland/electron-forge/issues/356
I can confirm exactly the same behaviour as reported by @matthewtoast. We are having this issue for the last 3 months. The interesting thing is that it always happens on our CI (jenkins in docker, official image) and on machines with macOS, but it never happend to me on archlinux.
Yarn version: 1.2.1
Node Version: 8.9.0
Also having issues with this when running yarn inside Docker. I haven't seen it outside Docker, but I don't use it much outside Docker either.
Yarn version: 1.2.1
Node version: 6.10.3
Host machine: OSX 10.12.6
Docker version: 17.09.0-ce-mac35
Same thing is happening here, sometimes it passes, sometimes it doesn't. It's not connected to any mutex configuration, as it happens with all.
Yarn 1.3.2
Node: 8.8.1
OS X 10.12.6
For me it was a disk space issue. I was running out of inodes (df -i
).
Once settled, yarn --prod
was successful.
Getting this error a lot with random missing files in Docker node:9
image. Not sure if it has something to do with docker-compose mounting the files from host? This makes yarn un-usable as I can't install anything, it all results in the same error. Only "fix" I've found is deleting the entire node modules folder and re-installing. This only seems to work for a bit.
Error: ENOENT: no such file or directory, copyfile '/usr/local/share/.cache/yarn/v1/npm-ansi-bgwhite-0.1.1-6504651377a58a6ececd0331994e480258e11ba8/package.json' -> '/app/node_modules/ansi-bgwhite/package.json'
Arguments: /usr/local/bin/node /opt/yarn-v1.5.1/bin/yarn.js install
PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Yarn version: 1.5.1
Node version: 9.10.1
Platform: linux x64
Getting the same error consistently.
Arguments:
/usr/local/Cellar/node/8.9.1/bin/node /usr/local/Cellar/yarn/1.6.0/libexec/bin/yarn.js
PATH:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/lib/node_modules/.bin:/usr/local/lib/node_modules/.bin
Yarn version:
1.6.0
Node version:
8.9.1
Platform:
darwin x64
Trace:
Error: ENOENT: no such file or directory, lstat '/Users/gary/Documents/code/build/packages/api-core/node_modules/envkey'
I have started experiencing this issue as well. I've tried different fixes but it just seems to vary to which file is the issue.
It may be of note that I am running bash on ubuntu with windows 10
i'm on yarn 1.5.1 will try updating now
update: problem persists
I see this running v1.7.0 on MacOS. This was occurring consistently in a large project that uses yarn workspaces with liberal nohoist
patterns, but hadn't happened in small, simple projects on the same machine.
yarn-error.log
Arguments:
/usr/local/bin/node /usr/local/Cellar/yarn/1.7.0/libexec/bin/yarn.js install --network-concurrency 1
PATH:
/Users/mike/Applications/google-cloud-sdk/bin:/Users/mike/.cargo/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin
Yarn version:
1.7.0
Node version:
10.7.0
Platform:
darwin x64
Trace:
Error: ENOTDIR: not a directory, lstat '/Users/mike/Code/boltline/app/packages/boltline-native/node_modules/@boltline/grades/node_modules/expand-brackets/node_modules/debug/.eslintrc'
npm manifest:
{
"private": true,
"license": "UNLICENSED",
"author": "Mike Marcacci <[email protected]>",
"scripts": {
"lint": "flow && eslint .",
"precommit": "lint-staged",
"prettier": "prettier \"packages/*/src/**/*.{js,css,.md}\" --write",
"deploy": "scripts/deploy.sh",
"dev": "scripts/dev.sh"
},
"repository": {
"url": "https://github.com/boltline/app.git",
"type": "git"
},
"workspaces": {
"packages": [
"packages/core",
"packages/grades",
"packages/boltline-native",
"packages/boltline-web"
],
"nohoist": [
"**/**",
"**/@boltline/core",
"**/react-native",
"**/react-native/**",
"**/@mapbox/react-native-mapbox-gl",
"**/@mapbox/react-native-mapbox-gl/**",
"**/react-native-*",
"**/react-native-*/**",
"**/vm-browserify",
"**/vm-browserify/**"
]
},
"devDependencies": {
"husky": "^0.14.3"
},
"dependencies": {}
}
yarn manifest:
No manifest
Lockfile:
No lockfile
I tried many different tricks (clearing cache, limiting network concurrency, etc) but what finally succeeded was making sure @boltline/grades
was declared as a dependency in all its sibling packages. This may just be coincidence, but also might suggest a starting point for someone more familiar w/ yarn internals.
Windows 10
Node 8.11.1
NPM 5.6.0
yarn 1.9.4
Running on bash (via WSL) inside VSCode.
Running yarn install
succeeds through "Resolving Packages...", "Fetching packages..." then fails on "Linking dependencies..." references ENOENT
with either lstat
or scandir
. The file referenced changes every time, and does _not_ exist.
Further investigation shows that the "Fetching packages..." stage doesn't _actually_ fetch anything. It creates the entire directory tree under /node_modules/
, but doesn't download a single file. It also completes lightning fast, and doesn't produce any error/warning.
Running sudo yarn install
works.
This is likely related to WSL and filesystem permissions more than yarn, but it would be nice if yarn produced some kind of error/warning message at "Fetching packages..." when it actually fails to do so.
for fellow googlers having the same problem: its a file system restriction.
Windows 10, Ubuntu Bash & yarn when even sudo yarn install does not work, while highly discouraged doing so, will probably fix it:
sudo chown -R domi:domi /usr/local/
sudo yarn install --network-timeout 10000000
warning: your node modules will be installed with root rights which is a potential security risk. This however fixes days not beeing able to install any yarn package
This is unfathomably frustrating, especially when running yarn upgrade-interactive --latest
with yarn workspaces, since failure clears out your version selections. Over the last few months, this has cost days of trial and inevitable error, and if we hadn't invested in yarn workspaces, we would just use NPM.
My strategy now is to run it in a loop until it succeeds. Here's for other sorry souls who are at their wit's end and just want the damn packages installed:
until yarn; do; echo "Surprise, surprise. Let's try again..."; done
Run that, set your laptop away from anything flammable, and go get dinner. Best luck.
I actually believe I might have a hypothesis of the issue here.
How many of you use watcher processes, such as auto-build, hot reload or automated localhost servers defined at scripts
section of the package.json file? When I turn these off, I do not have to use sudo or other tricks. This might be related to the fact that system user has much more file I/O privileges than regular users and many JS packages do have thousands of files; so if your watchers triple that amount of file I/O, then you might just meet the cap of 8000 files.
I didn't have this issue at older machine, when I had increased the file cap due to building really fast web scraper, which used temp/shm as storage.
I'm having this issue now.
Even retrying many times does not solve it. I thought I would give yarn a go to use the workspaces feature.
Now I'm worried I made the wrong choice, finding several old unresolved issues like this one about this weird issue 馃槄
Solving this temporarily with yarn install || yarn install || yarn install
to try three times, and migrating everything to use lerna and npm instead. No idea how to attack this without spending more valuable time since the logs are so lacking of any information
I've tried sudo yarn install, I've tried older versions of yarn I've tried doing it in docker, I've tried configuring max concurrency etc. Nothing solves it so far.
I was getting this same frustrating and hard to debug error. The problem in my case seemed to be yarn workspace
behaviour caused by different versions of the same dependency in different packages (specifically ava
versions 2 and 3). Only once I'd upgraded all occurrences of ava
to their latest did I stop getting this error.
I can confirm I have the same issue with yarn workspace, when extensively using no-hoist
Can also confirm the issue started to appear after different version of the same dependency is used across the monorepo.
We also have "a large repo using workspaces and no-hoist". I see this issue 100% of the time when using any of
yarn upgrade
yarn upgrade-interactive
yarn add
But I can run yarn install
just fine. Running yarn v1.22.4
I have observed a very similar issue when trying to install a package with local path using yarn add file:./my-config
:
error An unexpected error occurred: "ENOENT: no such file or directory, scandir '/Users/me/Library/Caches/Yarn/v6/npm-tw-config-1.0.0-7015ab00-060c-4b4e-8b2e-388d8934c404-1599154091934/node_modules/my_config'".
info If you think this is a bug, please open a bug report with the information provided in "/Users/me/my-project/functions/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
The install command only seems to work when the relevant local path in package.json matches ../my-config
(./my-config
is actually a symlink to ../my-config
, and yet this same exact line works when using npm):
"dependencies": {
"my_config": "file:../my-config"
}
Most helpful comment
This is unfathomably frustrating, especially when running
yarn upgrade-interactive --latest
with yarn workspaces, since failure clears out your version selections. Over the last few months, this has cost days of trial and inevitable error, and if we hadn't invested in yarn workspaces, we would just use NPM.My strategy now is to run it in a loop until it succeeds. Here's for other sorry souls who are at their wit's end and just want the damn packages installed:
Run that, set your laptop away from anything flammable, and go get dinner. Best luck.