Error: ENOENT: no such file or directory, scandir '**/node_modules/node-sass/vendor'
mrking opened this issue · 60 comments
Followed the troubleshooting guide. I'm having an intermittent build issue with one of our projects. The appearance is that it happens randomly.
See comment for solution
I'm using gulp-sass@2.1.0
which has this as a dependency.
I suspect there might be some sort of concurrency issue with the download of binaries in that specific folder. I've tried switching to several different node and npm versions now to see if the problem is related but hasn't resolved the issue.
Node v4.4.5
NPM 3.5.3
{ http_parser: '2.5.2',
node: '4.4.5',
v8: '4.5.103.35',
uv: '1.8.0',
zlib: '1.2.8',
ares: '1.10.1-DEV',
icu: '56.1',
modules: '46',
openssl: '1.0.2h' }
linux
x64
Ubuntu 16.04
On builds that do run successfully, I'll get the following message before NPM quits
Binary downloaded and installed at /home/jenkins/development/node_modules/node-sass/vendor/linux-x64-46/binding.node
"/home/jenkins/development/node_modules/node-sass/vendor/linux-x64-46/binding.node" exists.
testing binary.
Binary is fine; exiting.
Otherwise this error will happen during the build
[01:09:46] 'sass' errored after 16 ms
[01:09:46] Error: ENOENT: no such file or directory, scandir '/home/jenkins/development/node_modules/node-sass/vendor'
at Error (native)
at Object.fs.readdirSync (fs.js:808:18)
at Object.getInstalledBinaries (/home/jenkins/development/node_modules/node-sass/lib/extensions.js:74:13)
at foundBinariesList (/home/jenkins/development/node_modules/node-sass/lib/errors.js:20:15)
at foundBinaries (/home/jenkins/development/node_modules/node-sass/lib/errors.js:15:5)
at Object.module.exports.missingBinary (/home/jenkins/development/node_modules/node-sass/lib/errors.js:45:5)
at Object.<anonymous> (/home/jenkins/development/node_modules/node-sass/lib/index.js:14:28)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
npm ERR! Linux 3.13.0-85-generic
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "run-script" "build"
npm ERR! node v4.4.5
npm ERR! npm v3.5.3
npm ERR! code ELIFECYCLE
npm ERR! lexi@1.0.0 build: `gulp testfail lintfail babel sass hb`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the lexi@1.0.0 build script 'gulp testfail lintfail babel sass hb'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the lexi package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! gulp testfail lintfail babel sass hb
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs lexi
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls lexi
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR! /home/jenkins/development/npm-debug.log
Gulp Sass installation doesn't seem to be catching the Vendor binaries every time even manually installing.
sudo npm install gulp-sass
npm WARN deprecated cross-spawn-async@2.2.4: cross-spawn no longer requires a build toolchain, use it instead!
- lru-cache@4.0.1 node_modules/cross-spawn-async/node_modules/lru-cache
lexi@1.0.0 /home/jenkins/development
├─┬ gulp@3.9.1
│ └─┬ vinyl-fs@0.3.14
│ └─┬ glob-watcher@0.0.6
│ └─┬ gaze@0.5.2
│ └─┬ globule@0.1.0
│ └─┬ minimatch@0.2.14
│ └── lru-cache@2.7.3
├─┬ gulp-sass@2.3.1
│ └─┬ node-sass@3.7.0
│ ├─┬ cross-spawn-async@2.2.4
│ │ └── lru-cache@4.0.1
│ ├─┬ gaze@1.0.0
│ │ └─┬ globule@0.2.0
│ │ └─┬ minimatch@0.2.14
│ │ └── lru-cache@2.7.3
│ └─┬ node-gyp@3.3.1
│ └─┬ minimatch@1.0.0
│ └── lru-cache@2.7.3
├─┬ jshint@2.9.2
│ └─┬ cli@0.6.6
│ └─┬ glob@3.2.11
│ └─┬ minimatch@0.3.0
│ └── lru-cache@2.7.3
└─┬ mocha@2.5.3
└─┬ glob@3.2.11
└─┬ minimatch@0.3.0
└── lru-cache@2.7.3
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.12
npm WARN enoent ENOENT: no such file or directory, open '/home/jenkins/development/node_modules/languages.css/package.json'
mike@lexi3:/home/jenkins/development$ ls node_modules/node-sass/
bin binding.gyp lib node_modules package.json README.md scripts src
But installing node-sass manually seems to force the binaries to get downloaded
mike@lexi3:/home/jenkins/development$ sudo npm install node-sass@3.4.2
npm WARN deprecated npmconf@2.1.2: this package has been reintegrated into npm and is now out of date with respect to npm
npm WARN deprecated cross-spawn-async@2.2.4: cross-spawn no longer requires a build toolchain, use it instead!
> node-sass@3.4.2 install /home/jenkins/development/node_modules/node-sass
> node scripts/install.js
Binary downloaded and installed at /home/jenkins/development/node_modules/node-sass/vendor/linux-x64-46/binding.node
> spawn-sync@1.0.15 postinstall /home/jenkins/development/node_modules/spawn-sync
> node postinstall
> node-sass@3.4.2 postinstall /home/jenkins/development/node_modules/node-sass
> node scripts/build.js
` /home/jenkins/development/node_modules/node-sass/vendor/linux-x64-46/binding.node ` exists.
testing binary.
Binary is fine; exiting.
- lru-cache@4.0.1 node_modules/cross-spawn-async/node_modules/lru-cache
- minimatch@3.0.0 node_modules/node-sass/node_modules/glob/node_modules/minimatch
- glob@7.0.3 node_modules/node-sass/node_modules/glob
- minimatch@0.3.0 node_modules/node-sass/node_modules/globule/node_modules/glob/node_modules/minimatch
- glob@3.2.11 node_modules/node-sass/node_modules/globule/node_modules/glob
- lodash@2.4.2 node_modules/node-sass/node_modules/lodash
- minimatch@0.2.14 node_modules/node-sass/node_modules/minimatch
- globule@0.2.0 node_modules/node-sass/node_modules/globule
- gaze@1.0.0 node_modules/node-sass/node_modules/gaze
- in-publish@2.0.0 node_modules/in-publish
lexi@1.0.0 /home/jenkins/development
├─┬ babel-cli@6.9.0
│ └─┬ request@2.72.0
│ └─┬ bl@1.1.2
│ └── readable-stream@2.0.6
├─┬ gulp-autoprefixer@3.1.0
│ └─┬ through2@2.0.1
│ └── readable-stream@2.0.6
├─┬ jshint@2.9.2
│ └─┬ cli@0.6.6
│ └─┬ glob@3.2.11
│ └─┬ minimatch@0.3.0
│ └── lru-cache@2.7.3
├─┬ mocha@2.5.3
│ └─┬ glob@3.2.11
│ └─┬ minimatch@0.3.0
│ ├── lru-cache@2.7.3
│ └── sigmund@1.0.1
└─┬ node-sass@3.4.2
├─┬ cross-spawn@2.2.3
│ ├─┬ cross-spawn-async@2.2.4
│ │ └── lru-cache@4.0.1
│ └─┬ spawn-sync@1.0.15
│ ├─┬ concat-stream@1.5.1
│ │ ├── readable-stream@2.0.6
│ │ └── typedarray@0.0.6
│ └── os-shim@0.1.3
├─┬ gaze@0.5.2
│ └─┬ globule@0.1.0
│ └─┬ minimatch@0.2.14
│ ├── lru-cache@2.7.3
│ └── sigmund@1.0.1
├─┬ node-gyp@3.3.1
│ └─┬ minimatch@1.0.0
│ └── lru-cache@2.7.3
└─┬ npmconf@2.1.2
├─┬ config-chain@1.1.10
│ └── proto-list@1.2.4
└── uid-number@0.0.5
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.12
npm WARN enoent ENOENT: no such file or directory, open '/home/jenkins/development/node_modules/languages.css/package.json'
It appears that there was a permissions issue running install.js.
I'm not sure why it was doing it intermittently, but I simply changed the access rights to the build folder.
NPM seems to not give you a notification if install.js fails to run correctly.
Simlar problem with node-sass v3.7.0. I get the following error:
Error: ENOENT: no such file or directory, scandir 'C:\Working\my-app\node-sass\vendor'
In the package.json file it is looking for the "vendor" directory, which doesn't exist:
"files": [
"bin",
"binding.gyp",
"lib",
"scripts",
"src",
"vendor"
],
Rolling back "node-sass" to "3.4.0" temporarily fixed the issue for me. However, I am now locked into this version.
Note your Gulp-Sass installation referenced above is installing:
node-sass@3.7.0
But when you do it manually you are installing:
node-sass@3.4.2
Version 3.4.2 doesn't have "vendor" in the "files" array I referred to in previous comment, but version 3.7.0 does.
package.json version 3.4.2:
"files": [
"bin",
"binding.gyp",
"lib",
"scripts",
"src"
],
package.json version 3.7.0:
"files": [
"bin",
"binding.gyp",
"lib",
"scripts",
"src",
"vendor"
],
The vendor directory is created during npm install. Try deleting your
node_modules and running npm install.
On 22 Jun 2016 2:02 AM, "dustin-page" notifications@github.com wrote:
Note your Gulp-Sass installation referenced above is installing:
node-sass@3.7.0But when you do it manually you are installing:
node-sass@3.4.2Version 3.4.2 doesn't have "vendor" in the "files" array I referred to in
previous comment, but version 3.7.0 does.package.json version 3.4.2:
"files": [
"bin",
"binding.gyp",
"lib",
"scripts",
"src"
],package.json version 3.7.0:
"files": [
"bin",
"binding.gyp",
"lib",
"scripts",
"src",
"vendor"
],—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1579 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAjZWIJUYcMtWAKcDWs5fXNLpdHbggo7ks5qOArvgaJpZM4Ivk6Q
.
Just to update from my end. I found that for some reason no matter what I did even after the permissions issue was resolved, it still wouldn't always run the install.js script. I also noticed it tends to happen when its only part of a large set of downloads.
As a safe guard, I just started running the install.js file after NPM Install command part of my build. This ensured that the vendor folder was always present.
Can't explain why the install file doesn't always get ran on each build. So my build script looks like this:
npm update
npm install
nodejs node_modules/node-sass/scripts/install.js
npm rebuild node-sass
npm will only execute install scripts for direct dependencies in your package.json. This is a performance optimisation on their end which is unfortunate.
npm rebuild node-sass
is the official solution. Deleting your node_modules and running npm install
will also do the trick.
This problem was happening on a build server where the folder was clean on each build. So your suggestion of deleting the node_modules folder didn't fix the issue in my case as there wasn't a node_modules folder to begin with.
I don't know enough about how NPM works to comment on your bit of information. If you want me to do any additional logging, I can still reproduce the problem fairly consistently. However, I have my work around for now 👍
However, seeing no one else has reported this until now, whatever it is, its not widespread. Probably not good utilization of time.
This commonly happens in CI systems because they'll typically run npm install
with the default OS Node. Later in their script they'll switch a new version of Node. Native extension are compiled against the version of Node that npm
was using during install. This means the new Node cannot see the extension built during install.
In this case, running npm install
again doesn't fix the issue because npm thinks it is installed. This is why you must run npm rebuild node-sass
.
Can you please help me figure out what's causing the issue? Here's how I can reproduce it:
$ node -e 'require("gulp-sass")'
fs.js:808
return binding.readdir(pathModule._makeLong(path));
^
Error: ENOENT: no such file or directory, scandir '/home/rm/app/shared/node_modules/gulp-sass/node_modules/node-
sass/vendor'
at Error (native)
at Object.fs.readdirSync (fs.js:808:18)
at Object.getInstalledBinaries (/home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass/lib/extens
ions.js:119:13)
at foundBinariesList (/home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass/lib/errors.js:20:15)
at foundBinaries (/home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass/lib/errors.js:15:5)
at Object.module.exports.missingBinary (/home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass/li
b/errors.js:45:5)
at Object.<anonymous> (/home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass/lib/index.js:15:28)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
But after npm rebulid node-sass
it indeed succeeds:
$ cd node_modules/gulp-sass/
$ npm rebuild node-sass
> node-sass@3.8.0 install /home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass
> node scripts/install.js
Binary downloaded and installed at /home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass/vendor/linux-x64-46/binding.node
> node-sass@3.8.0 postinstall /home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass
> node scripts/build.js
"/home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass/vendor/linux-x64-46/binding.node" exists.
testing binary.
Binary is fine; exiting.
node-sass@3.8.0 /home/rm/app/shared/node_modules/gulp-sass/node_modules/node-sass
$ cd ../..
$ node -e 'require("gulp-sass")'
$ echo $?
0
node
was installed with this ansible role. And I believe, it was installed once. No node
was before that. Also, most likely (about to confirm) it worked fine with node-0.12
(or so), but broke with node-4.4.7
. Additionally, it supposedly works with node-4.x
on CentOS 7. All before the last bit was about Ubuntu (trusty
, xenial
).
UPD Can't reproduce anymore.
nodejs node_modules/node-sass/scripts/install.js
npm rebuild node-sass
I ran this for every package that gave ENOENT and now everything if working.
thanks alot!
for some reason the install script wasn't invoked when i ran npm install
(for fellow search engine travellers)
I ran into the same error message, but found it had to do with the metadata of our internal "mirror" of npm.
npm seems to use the scripts
field of the registry entry instead of that in the package.json in the tgz. In our case, manually publishing node-sass 3.8.0 and 3.10.0 resulted in the scripts
key being an empty map. npm thus had no idea there was more work to do.
@PixnBits thank you, this is good to know. How did you manually publish node-sass? How can one reproduce this?
Had the same problem. After running
npm update
Everything worked fine
npm rebuild node-sass
I have same problem, run npm rebuild node-sass
resolve it.
npm rebuild node-sass
I have same problem, run npm rebuild node-sass resolve it.
@saper probably an npm issue, but from memory:
- start an instance of sinopia
npm pack node-sass@3.8.0
npm publish node-sass-3.8.0.tgz --registry=http://localhost:4873/
(or your sinopia location)npm info node-sass@3.8.0 scripts --registry=http://localhost:4873/
will be different thannpm info node-sass@3.8.0 scripts --registry=https://registry.npmjs.com
in that "install" and postinstall(?) will be missing from sinopia
Granted this cause may be moot as the proper way to "mirror" a registry is not to manually publish to the mirror, but to pull both metadata and tgz from the source registry.
Hi everybody,
When deploying to Heroku, I continue to have this issue even after running npm rebuild node-sass
. Does anybody else feel the same way?
@peterpme I was able to fix this on heroku by turning off NODE_MODULES_CACHE
heroku config:set NODE_MODULES_CACHE=false
Use npm install node-sass or Linux npm install node-sass --no-bin-links
Vagrant box can use: npm rebuild node-sass --no-bin-links
Thank for this topic.
We’ve just started having this issue intermittently on our build servers using Yarn 0.18.1. Our build was previously stable; we’re having a hard time figuring out what’s changed. Just posting here in case anyone else is also suddenly encountering this issue too.
Update: Our problem seems to be yarnpkg/yarn#1832
The workaround fix by @devmedios worked for our Docker CI pipeline. 😅
npm i node-sass --no-bin-links
Thanks!
I have the same problem, and after:
sudo npm rebuild node-sass
It was the solution to the problem...
@M2shad0w thank you. After running npm update
and npm rebuild node-sass
, node-sass
works now.
I've got the same issue here on Ubuntu, last node version and npm version...
npm ERR! node v6.10.0
npm ERR! npm v4.3.0
I tried everything including npm update, rebuild, rebuild with no bin links, nothing works...
Any ideas ?
@schankam increase RAM.
@quietwind thank you!
Every 19 out of 20 deployments on heroku for my apps that use this package simply crash due to this problem :) I keep pushing the same commit until Heroku builds it. That seems to be the only solution right now, yes? Rebuild until it works?
sudo npm rebuild node-sass
did the trick here on MacOS as well.
Ubuntu 16.04 on Digital Ocean, sudo npm rebuild node-sass
did the trick for me as well
Thank you @mrking, simply npm rebuild node-sass
did the trick here (MacOS)
npm rebuild works sometimes. The only thing that always works for me to get rid of this ridiculous annoying bug is to just go npm install node-sass@random-compatible-different-version
npm rebuild node-sass
resolved it for me too.
The only thing I had to do on TravisCi was:
script:
- npm rebuild node-sass
- npm run build
After that it worked, thanks
This still happens with v4.5.3
I can't run the script because this happens on heroku
@pencilcheck - I was running into the same issue. Add
npm rebuild node-sass &&
Before your build/start script for heroku and it'll recompile node sass before building your app packages.
But exactly what is the cause of the problem?
Seeing this often when deploying to Dokku. It's a major problem for us right now. Causes a lot of deploys to fail.
This seems to happen pretty consistently with the following setup:
First build
rm -rf node_modules
yarn install --pure-lockfile
tar c node_modules | gzip > .deploy-caches/node_modules.tar.gz
- Run build PASSES
Second build
rm -rf node_modules
cat .deploy-caches/node_modules.tar.gz | gzip | tar x
- Run build FAILS
This is how Travis handles caching of node_modules
and we only started having this problem when we switched to using yarn instead of npm.
If we avoid the cache and always yarn install --pure-lockfile
it seems to work.
I had this issue trying to deploy to Heroku after I started to import some css inside JS packs with Webpacker which uses Yarn. npm rebuild node-sass
did help, and one way to make it work during Heroku deployment is to put this to package.json:
"scripts": {
"postinstall": "npm rebuild node-sass"
}
Add more memory to vagrant machine fix the problem for me.
Seeing this issue with node-sass@4.5.3. I tried to do npm rebuild node-sass after creating vendor directory manually but that didn't help.
If you find yourself having this issue with node v^8
, that's because 3.13.1 is not friend of node8. #1945. I would recommend to downgrade your node to the last LTS version.
An easy way to insert the rebuild fix into a project is in the post install script - if you already have a post-install you can prepend it, for example with webpack:
{
"postinstall": "npm rebuild node-sass && env NODE_ENV=production webpack"
}
I ran into this problem with node 8.5.0 and node-sass 4.5.3. Fixed it by deleting the node_modules/node-sass
directory and reinstalling.
npm rebuild node-sass
fixed the issue for me.
Deleting node_modules/node-sass
and reinstalling didn't seem to work for me. @ERPedersen's solution worked.
I had the same issue. My installed version for node-sass
was 3.1.0
. I upgraded it to 3.7.0
which contains vendor files
and now it is working fine.
My Solution: I deleted the node-sass
from node_modules
directory and reinstalled using npm install
hi,
reinstalling only works once...
after every 'yarn add' or 'yarn install' operation, the node-sass vendor folder is deleted again.
only solution (for me) currently:
npm rebuild node-sass
outside from yarn!!! (executing in script from yarn e.g 'yarn node:rebuild' does not work !)
i still have this error with yarn 1.6.0
Create the vendor directory in node_sass directory . It worked for me.
mkdir '...../node_modules/node-sass'
mkdir '....../node_modules/node-sass/vendor'
Having this issue, using npm...
node-sass 4.11.0
Having this issue, using npm...
node-sass 4.11.0
try running node ./node_modules/node-sass/scripts/install.js
it worked for me
This problem started appearing after rebuilding our docker image today (no change to Dockerfile content), reverting back to old docker image works.
the docker file looks like this:
FROM node:8.9-slim
RUN apt-get update && \
apt-get install -y --no-install-recommends git mysql-client openssh-client \
python \
libcairo2-dev libjpeg-dev libpango1.0-dev libgif-dev build-essential g++ \
libpng-dev && \
npm i -g yarn lerna && \
rm -rf /var/lib/apt/lists/*
so the problem is one of the following:
- node / npm
- yarn
- lerna
- other OS packages
The weird thing is, even after fixing the version of yarn and lerna, the problem still exists:
npm i -g yarn@1.12.3 lerna@3.4.3 && \
Same issue suddenly appeared magically in Dockerfile builds. Downgraded npm 6.6 to 6.5 and then it worked again.
Update:
- Adding more native packages in
apt-get install
does NOT help to solve the problem. - We ended up adding a
npm rebuild
post-install
step to all the packages that are giving these native dependency errors (not justnode-sass
, other image processing npm libraries also have the same issue). This works with the newly rebuilt Docker images (without adding extra native packages).
Not sure if there's a way to avoid that.