New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: ENOENT: no such file or directory, scandir '**/node_modules/node-sass/vendor' #1579

Closed
mrking opened this Issue Jun 7, 2016 · 55 comments

Comments

Projects
None yet
@mrking

mrking commented Jun 7, 2016

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'
@mrking

This comment has been minimized.

mrking commented Jun 7, 2016

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.

@mrking mrking closed this Jun 7, 2016

@dustin-page

This comment has been minimized.

dustin-page commented Jun 21, 2016

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.

@dustin-page

This comment has been minimized.

dustin-page commented Jun 21, 2016

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"
],

@xzyfer

This comment has been minimized.

Contributor

xzyfer commented Jun 21, 2016

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.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"
],


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
.

@mrking

This comment has been minimized.

mrking commented Jun 22, 2016

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

@xzyfer

This comment has been minimized.

Contributor

xzyfer commented Jun 22, 2016

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.

@mrking

This comment has been minimized.

mrking commented Jun 22, 2016

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.

@xzyfer

This comment has been minimized.

Contributor

xzyfer commented Jun 22, 2016

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.

@x-yuri

This comment has been minimized.

x-yuri commented Jul 9, 2016

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.

rmacqueen added a commit to shareonbazaar/bazaar that referenced this issue Aug 11, 2016

Add 'enact' install script to ensure node_sass module gets installed
Node-sass-middleware has a dependency module, node-sass, which
needs to get installed first. Unfortunately, for some reason,
the current version of node-sass does not properly run
its install script to download the binary file it needs to
operate. See sass/node-sass#1579
for more details.

To fix this, we hadd an 'enact' script to elasticbeanstalk
configuration, to tell it to run the node-sass installer
manually during deployment. This ensures that the binary
file gets installed.

rmacqueen added a commit to shareonbazaar/bazaar that referenced this issue Aug 11, 2016

Add 'enact' install script to ensure node_sass module gets installed
Node-sass-middleware has a dependency module, node-sass, which
needs to get installed first. Unfortunately, for some reason,
the current version of node-sass does not properly run
its install script to download the binary file it needs to
operate. See sass/node-sass#1579
for more details.

To fix this, we hadd an 'enact' script to elasticbeanstalk
configuration, to tell it to run the node-sass installer
manually during deployment. This ensures that the binary
file gets installed.
@Nexxado

This comment has been minimized.

Nexxado commented Sep 29, 2016

@mrking

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

@PixnBits

This comment has been minimized.

PixnBits commented Oct 2, 2016

(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.

@saper

This comment has been minimized.

Member

saper commented Oct 4, 2016

@PixnBits thank you, this is good to know. How did you manually publish node-sass? How can one reproduce this?

@mitajunior

This comment has been minimized.

mitajunior commented Nov 26, 2016

Had the same problem. After running

npm update

Everything worked fine

@QuietWind

This comment has been minimized.

QuietWind commented Dec 2, 2016

npm rebuild node-sass

I have same problem, run npm rebuild node-sass resolve it.

glechev pushed a commit to vmware/admiral that referenced this issue Dec 12, 2016

Fix failing build with "npm WARN reflux@0.3.1 requires a peer of
react@>=0.12.2 <0.15.0 but none was installed."

- added 'npm rebuild node-sass'. For more information:
sass/node-sass#1579

Change-Id: Ia3fdf59e3b3dfc8b9686801c63f48b7f1c10e3aa
Reviewed-on: http://bellevue-ci.eng.vmware.com:8080/4764
Reviewed-by: Zahari Ivanov <zaharii@vmware.com>
Reviewed-by: Tony Georgiev <tgeorgiev@vmware.com>
CS-Verified: jenkins <jenkins@vmware.com>
Bellevue-Verified: jenkins <jenkins@vmware.com>

glechev pushed a commit to vmware/admiral that referenced this issue Dec 13, 2016

Fix failing build with "npm WARN reflux@0.3.1 requires a peer of
react@>=0.12.2 <0.15.0 but none was installed."

- added 'npm rebuild node-sass'. For more information:
sass/node-sass#1579

Change-Id: Ia3fdf59e3b3dfc8b9686801c63f48b7f1c10e3aa
Reviewed-on: http://bellevue-ci.eng.vmware.com:8080/4765
Reviewed-by: Tony Georgiev <tgeorgiev@vmware.com>
Bellevue-Verified: e_vcoauto_glob_1 <e_vcoauto_glob_1@vmware.com>
CS-Verified: e_vcoauto_glob_1 <e_vcoauto_glob_1@vmware.com>
@ERPedersen

This comment has been minimized.

ERPedersen commented Sep 30, 2017

npm rebuild node-sass fixed the issue for me.

@davidcalhoun

This comment has been minimized.

davidcalhoun commented Nov 16, 2017

Deleting node_modules/node-sass and reinstalling didn't seem to work for me. @ERPedersen's solution worked.

oliverguenther added a commit to opf/openproject that referenced this issue Nov 22, 2017

oliverguenther added a commit to opf/openproject that referenced this issue Nov 22, 2017

artemv added a commit to artemv/rollout_dashboard that referenced this issue Dec 19, 2017

oliverguenther added a commit to opf/openproject that referenced this issue Jan 18, 2018

oliverguenther added a commit to opf/openproject that referenced this issue Feb 8, 2018

@jdeck88 jdeck88 referenced this issue Feb 23, 2018

Closed

npm install fails #5

n-riesco added a commit to n-riesco/react-chart-editor that referenced this issue Mar 19, 2018

@yugi03

This comment has been minimized.

yugi03 commented Apr 9, 2018

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.

gmouchakis pushed a commit to semagrow/semagrow that referenced this issue Apr 17, 2018

@shivabhusal

This comment has been minimized.

shivabhusal commented May 8, 2018

My Solution: I deleted the node-sass from node_modules directory and reinstalled using npm install

@Tenvan

This comment has been minimized.

Tenvan commented May 9, 2018

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 !)

@xzyfer

This comment has been minimized.

Contributor

xzyfer commented May 9, 2018

@Tenvan

This comment has been minimized.

Tenvan commented May 11, 2018

i still have this error with yarn 1.6.0

@mqliutie

This comment has been minimized.

mqliutie commented May 15, 2018

@mrking Thanks

@Anant-Raj

This comment has been minimized.

Anant-Raj commented May 21, 2018

Create the vendor directory in node_sass directory . It worked for me.

mkdir '...../node_modules/node-sass'
mkdir '....../node_modules/node-sass/vendor'

@xgqfrms xgqfrms referenced this issue May 30, 2018

Open

webpack & bug #9

@xgqfrms

This comment has been minimized.

xgqfrms commented May 30, 2018

node-sass & bug

Module build failed: Error: ENOENT: no such file or directory, scandir 'node_modules\node-sass\vendor'

image

solution

delete node_modules folder & re-install all modules

OR

delete package.json "node-sass": "^4.7.2", & re-install npm i -D node-sass@4.7.2

OK

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment