Installing node-sassusing latest Yarn results in ENOENT for node-sass/vendor

[jbruni]

Steps I did:

• Installed fresh new Yarn 0.17.0 using npm install yarn -g
• Removed both node_modules and yarn.lock from my project's root
• Ran yarn to install dependencies from project's package.json (including node-sass 3.12.2)
• Ran a webpack task which uses node-sass

Result:

fs.js:951
  return binding.readdir(pathModule._makeLong(path), options.encoding);
                 ^
Error: ENOENT: no such file or directory, scandir '/home/jbruni/project/node_modules/node-sass/vendor'
    at Error (native)
    at Object.fs.readdirSync (fs.js:951:18)
    at Object.getInstalledBinaries (/home/jbruni/project/node_modules/node-sass/lib/extensions.js:121:13)
    at foundBinariesList (/home/jbruni/project/node_modules/node-sass/lib/errors.js:20:15)
    at foundBinaries (/home/jbruni/project/node_modules/node-sass/lib/errors.js:15:5)
    at Object.module.exports.missingBinary (/home/jbruni/project/node_modules/node-sass/lib/errors.js:45:5)
    at module.exports (/home/jbruni/project/node_modules/node-sass/lib/binding.js:15:30)
    at Object.<anonymous> (/home/jbruni/project/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)

Important:

1. If I do npm rebuild node-sass and run the task again, everything goes well. The error vanishes.

2. I have done the procedure described in the steps above several times lately, and it has been working.

3. It seems Yarn used to automatically run the "build node-sass" process, but it is not doing anymore.

I can't tell if this is due to Yarn (likely to be) or node-sass, because both had new releases today. I'm only reporting for your acknowledgement, so you can proceed with the appropriate action.

Thank you.

---

• YARN version (yarn --version): 0.17.0
• NPM version (npm -v): 3.10.8
• Node version (node -v): v6.7.0
• Node Process (node -p process.versions):

{ http_parser: '2.7.0',
  node: '6.7.0',
  v8: '5.1.281.83',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '57.1',
  modules: '48',
  openssl: '1.0.2j' }

• Node Platform (node -p process.platform): linux
• Node architecture (node -p process.arch): x64
• node-sass version (node -p "require('node-sass').info"):

node-sass	3.12.2	(Wrapper)	[JavaScript]
libsass  	3.3.6	(Sass Compiler)	[C/C++]

• npm node-sass versions (npm ls node-sass):

/home/jbruni/project
└── node-sass@3.12.2 

[xzyfer]

Thanks for the report. Could you please create gist with full install log output?

[jbruni]

@xzyfer - here is it: https://gist.github.com/jbruni/e089a168b7070bc27c0bed6f78da678f

Nothing interesting, except (perhaps) by the absence of the final lines where (as far as I remember) node-sass build happened and appeared in the output...

[xzyfer]

Is there a more verbose output mode?

[xzyfer]

I just a did a local test with both yarn 0.16.1 and 0.17.0 against node-sass@v3.12.2 without any issue.

[CJBridges]

I have an internal project that has the same behavior/workaround.
Yarn 0.17.0 (with lockfile)
node-sass version 3.4.1

node-ass was previously installed fine with Yarn 0.16.1.

[xzyfer]

Hmm node-sass@3.4.1 has been stable for a long time. This appears to be a yarn issue.

[bpossolo]

I'm having this issue with npm (not using yarn).
Looks like it's expecting a file from a package called gauge (which is pulled in by npmlog) but not finding it.

> node-sass@3.12.3 install /mnt/ephemeral/var/lib/jenkins/jobs/FE_SEO_Release_QA/workspace/node_modules/node-sass
> node scripts/install.js

http node-sass install Downloading binary from https://github.com/sass/node-sass/releases/download/v3.12.3/linux-x64-14_binding.node
�[?25l
�[K�[?25h/mnt/ephemeral/var/lib/jenkins/jobs/FE_SEO_Release_QA/workspace/node_modules/gauge/render-template.js:67
          throw new error.MissingTemplateValue(cloned, values)
                ^
Error: Missing template value "progressbar"
    at cloneAndObjectify (/mnt/ephemeral/var/lib/jenkins/jobs/FE_SEO_Release_QA/workspace/node_modules/gauge/render-template.js:67:17)
    at Array.map (native)
    at prepareItems (/mnt/ephemeral/var/lib/jenkins/jobs/FE_SEO_Release_QA/workspace/node_modules/gauge/render-template.js:83:25)
    at module.exports (/mnt/ephemeral/var/lib/jenkins/jobs/FE_SEO_Release_QA/workspace/node_modules/gauge/render-template.js:16:15)
    at Object.Plumbing.show (/mnt/ephemeral/var/lib/jenkins/jobs/FE_SEO_Release_QA/workspace/node_modules/gauge/plumbing.js:45:10)
    at Object.Gauge._doRedraw (/mnt/ephemeral/var/lib/jenkins/jobs/FE_SEO_Release_QA/workspace/node_modules/gauge/index.js:219:40)
    at null.<anonymous> (/mnt/ephemeral/var/lib/jenkins/jobs/FE_SEO_Release_QA/workspace/node_modules/gauge/index.js:15:19)
    at wrapper (timers.js:274:14)
    at Timer.unrefdHandle (timers.js:307:14)

[xzyfer]

@bpossolo you issue is unrelated and fixed in v3.12.5

[jbruni]

@xzyfer - I tried but couldn't find more verbose output. Now I'm getting this other error. Latest Yarn became unusable for me. I reverted to previous released version (yarn 0.16.1), and I have no issues anymore. Everything installs just fine, including node-sass.

And yes: in the end of the process, I can see it quickly building (or downloading) node-sass in the progress status. This is absent when using Yarn 0.17.0

I think we can close this issue, since all evidences point to being a Yarn issue.

[xzyfer]

Thanks all

[devcer]

I was getting the same error! I just migrated my project from npm to yarn but when i use gulp dev i got the error as mentioned in the beginning. I copied the vendor folder from node_modules of npm install to node_modules of yarn and everything was perfect after that.

[karol-f]

Latest yarn@0.17.2 fixed issue for me.

[devcer]

I m using the same yarn version! :(

[karol-f]

@viswanathamsantosh maybe remove node_modules and yarn install again?

[devcer]

Yup! did it but still didn't worked.may be i will try on other machine and check.

[jbruni]

Yes, using Yarn 0.17.2 works. They reverted the change that introduced the bug.

[michaelmior]

This works fine for me in yarn 0.16.1, but still broken in yarn 0.17.x. Removed node_modules, reinstalled yarn then reran it when testing.

[firedev]

I can confirm the issue persist with 0.17.2, npm rebuild node-sass helped.

ERROR in ENOENT: no such file or directory, scandir 'node_modules/node-sass/vendor'

$ npm rebuild node-sass
> node-sass@3.8.0 install node_modules/node-sass
> node scripts/install.js

Binary downloaded and installed at node_modules/node-sass/vendor/darwin-x64-48
/binding.node

> node-sass@3.8.0 postinstall node_modules/node-sass
> node scripts/build.js

"node_modules/node-sass/vendor/darwin-x64-48/binding.node" exists.
 testing binary.
Binary is fine; exiting.

[hauleth]

I can confirm with yarn 0.17.4.

[xzyfer]

@hauleth are you confirming the issue persists or is resolved in 0.17.4?

[firedev]

I can confirm issue persists with 0.17.6, have to do yarn && npm rebuild node-sass

[valscion]

@hauleth, @firedev, can you check whether this fixes your problems?

yarn cache clean
rm -rf node_modules
yarn install

It was suggested in yarnpkg/yarn#1832 (comment)

[karol-f]

@firedev I can't confirm. I had problems with 0.17.0 but when testing 0.17.2, 0.17.4 and 0.17.6 - it works fine on my end.

[lime]

The issue persists for me across all of 0.17.x, up to and including 0.17.6.

It's very difficult to create a reproducible case though. It does not occur in all projects where I use node-sass, and it does not occur consistently on every install.

Cleaning the cache / running yarn --force / removing node_modules may fix the symptoms for a while, but it's very likely that the problem will reappear later.

[hauleth]

It worked fine after some voodoo magic. But I agree with @lime that this is band-aid not full time solution.

[xzyfer]

This could be related to yarnpkg/yarn#1965 which was fixed in v0.17.7. Is someone able to confirm?

[michaelmior]

@xzyfer Seems fixed for me in v0.17.7 :)

[hlubek]

I still have this issue with v0.17.8

[wanghanlin]

same here, still have this issue with v0.17.8

[paulmsmith]

Yep. I had this issue today. 0.17.9 using npm rebuild node-sass fixed things though.

[ryank311]

I was having this same issue with 0.17.9 immediately after upgrading from 0.16.9. I think this may have been due to an issue with incompatible caches? After running yarn cache clean && rm -rf node_modules/ && yarn on 0.17, I'm not seeing the issues anymore.

[ctaepper]

i'm pretty sure it has something to do with caching... i run into this problem on my ci server. node-sass install script downloads the binary and caches it to .npm cache directory. but when using yarn, the cache that gets restored is not the npm cache, but the yarn cache. there is not vendor binary in the yarn cache...

[xzyfer]

Yes this a known issue with Yarn. We're leaving this issue open until there is a resolution.

[benjie]

Yarn v0.17.10 still has this issue when pushing to Heroku.

[primavera133]

Had this issue in yarn 0.17.10 Solved with 'yarn install --force'

[jtsternberg]

I get this error when running grunt sass after installing grunt-sass via npm install:

>> Error: ENOENT: no such file or directory, scandir '/PROJECT_PATH/node_modules/grunt-sass/node_modules/node-sass/vendor'

The /PROJECT_PATH/node_modules/grunt-sass/node_modules/node-sass/vendor directory does not exist. I know from another project that there should be /PROJECT_PATH/node_modules/grunt-sass/node_modules/node-sass/vendor/darwin-x64-46/binding.node file.

npm rebuild node-sass has no effect.

Any thoughts on how to get this build properly?

[michaelmior]

@jtsternberg It sounds like your issue is unrelated to Yarn. The first step would be to remove your node_modules directory and reinstall from scratch. If that doesn't work, you should probably open a separate issue.

[alexhgian]

@primavera133 Thanks this works, but the rebuild does add a little bit more time to the build compared to vanilla npm.

[kjs3]

Hitting this issue on Heroku with yarn 0.18.1 fwiw.

[xzyfer]

Yes this a known issue with Yarn. We're leaving this issue open until there is a resolution. Additional comments have been restricted.

[saper]

I think the problem is that there is no way to tell the packager to carry some files around but only locally. We have previously decided not to include binary bindings in the package itself.

[xzyfer]

Closing as stale. This is a yarn issue out of our control.