Travis Build Error: libsass bindings not found. Try reinstalling node-sass?

[grayghostvisuals]

Can someone please save my skull from being pounded firmly against the wall and tell me how I can find a fix? This is the output from Travis http://www.codeshare.io/Z2vdz Using gulp-sass 1.2.2. Here is my travis file as well. Thanks y'all

[kevva]

#497

[StoneCypher]

@kevva This doesn't seem to be #497, which describes several unrelated bugs, and the defect is still outstanding.

Are you certain this ticket should be closed?

[goodforenergy]

I'm using the latest version of gulp-sass which pulls in node-sass 2.0.0 beta, and I'm still experiencing this issue.

[am11]

@grayghostvisuals, add

env: 
  SKIP_SASS_BINARY_DOWNLOAD_FOR_CI=true 

to your .travis.yml. You can always use node-sass' own travis config for reference.

@StoneCypher, these are related issues. Some folks have not reported full logs and since the partial logs differ, hence the confusion. But rest assured most of the installation issues have commonalities.

@goodforenergy, are you facing the issue locally or on CI server? If it is happening locally, please execute these commands one at a time: https://gist.github.com/am11/e5de3c49c219f0811e1d#comment-1386582. If it fails, please create a similar GH gist with the produced output and share the link.

[grayghostvisuals]

@am11 Here's my current Travis file https://github.com/grayghostvisuals/transformicons/blob/master/.travis.yml

Do you think I still need to add that line you left above?

[am11]

@grayghostvisuals, apparently you are not getting the error described in this issue anymore. So no, you do not need to add that line.

Node-sass' install script first try to download the binary and test it. If the binary is corrupted or incompatible with your system, it falls back to manual compilation of binary (given the required tools are available on the system, otherwise it will fail the build).

It seems like it is downloading the correct version (v1.2.4) of node-sass binary which is compatible with OS run by TravisCI's VM. Though the current version of node-sass is v2.0.0-beta.

[goodforenergy]

@am11 - it is not happening locally. We use the frontend-maven-plugin to run a build task that downloads node and executes an npm install on the build machine, and operates out of a local node_modules folder for that project. The strange thing is that we have some projects doing the same thing on the same machine, and executing absolutely fine - but certain projects with no discernible differences in the setup will fail.

Our CI server doesn't have node installed globally, but I tried doing that and running the commands in the gist you linked, and everything seemed fine.

This is the output of a failed build, compared with one with no issues (a branch of the same project).

I did just notice that the version of node we install using that build task is a little behind.. will try updating.

Any advice is much appreciated.

[am11]

@goodforenergy, if this is happening intermittently on the same machine, it could be due to the network or timeout issue during node-sass being installed. I am not sure about the frontend-maven-plugin internals, but there might be a way to adjust the timeout to let the module finish its post-installation process. Moreover, there might be a way to get verbose output for each command executed.

Momentarily, taking a closer look at the failure logs suggest that it throws at clean step: Running 'gulp clean --no-color' ... before gulp build. Can you check if there is anything trying to require node-sass during clean process? (just curious: is the clean step necessary in your setup?)

[goodforenergy]

@am11 - thanks for the ideas. Thankfully / frustratingly, changing the node / npm version specified in frontend-maven-plugin to v0.10.36 / 1.4.12 magically resolved the issue.

I wonder though if you're right, and it's just a timing issue (and I've perhaps just been lucky with the last few builds). I had a look at the frontend-maven-plugin docs but there is no config available to specify a timeout.

We can probably do without a clean there, but the following task is a build, which definitely requires node-sass. The reason it's being required at that point is the structure of my gulp tasks - I've separated them into different task files and my gulpfile.js just requires all my task files to make them all available.

I could try explicitly requiring gulp-sass (which itself requires node-sass) inside my Sass task rather than at the top of my sass.js task file. If I moved the require I could also add a task to emulate a small delay between npm install and the rest of the tasks to see if that helps... except now I can't reproduce the issue to see if it will fix it (facepalm).

[am11]

@goodforenergy, see Heisenbug. 😃
(guessing here) if it is somehow downloading the older version of node-sass (v1.1.4), then binary related issue is possible. While the error suggests as if libsass is not downloaded, it might not be a partial download thingy but actually libc dependency thing (which was the issue with some prior versions of libsass). If the problem persist, would be worth a try to explicitly download npm install [email protected] (which would demand more changes, so hopefully that is not required).

[StoneCypher]

@goodforenergy It's worth remembering that gulp dependencies are a directed graph, not a tree. There's nothing stopping those dependencies from redundantly depending on one another, provided no cycles are created. It's perfectly fine for Z to depend on [a,b,c], then for C to also depend on [a,b], in the hope of resolving order of execution. Part of gulp's job is to find a sensible way to parallelize what remains of the ordering echelon.

Hope that helps

[apfelbox]

FWIW: I just had the reported issue in a case where I installed node-sass using node 10.x, updated node to 12.0 and then my script failed (in my case: a gulp task). Just completely wiping the node_modules directory and rerunning npm install (using node v12) fixed the issue.

Might not be related to the original issue, but this is the first match for this exact error message on google. Maybe it helps someone else.

[am11]

@apfelbox, starting with node-sass v2, node.js v0.12 and iojs v1.2 are supported. If you are running older version of node-sass and updated node.js to recently released v0.12 from v0.10, then you will face the issue. You can also explicitly specify the version when downloading the module; npm install [email protected].

[costa]

@am11 Thanks a lot, it actually worked.

[apfelbox]

@am11 I am running 2.0.1. The precompiled binary was placed in vendor/darwin-x64-node-0.10/ which was resolved in runtime by this piece of code (the last line):

var candidates = [
    path.join(__dirname, '..', 'build', 'Debug', 'binding.node'),
    path.join(__dirname, '..', 'build', 'Release', 'binding.node'),
    path.join(__dirname, '..', 'vendor', process.sassBinaryName, 'binding.node')
  ];

which returns darwin-x64-node-0.12 for node v12.x.

So my issue was just a simple mismatch in file paths. And that was easily solved by just running npm install. (please note: the reinstall would be necessary in either case, if the binaries differ between v10.x and v12.x. If they are ABI compatible the reinstallation wouldn't have been technically necessary, except of the change in directory name)

[am11]

@apfelbox that is right. npm install should be run once after updating node.js. This is not always the case though but only when the major or minor versions of node.js, io.js or atom-shell is incremented, then the npm modules which uses C++ add-ons need to be rebuild / reinstall. Which means when you upgrade node to v0.12.1, you will not have to reinstall it. But in case of v0.13.x or v1.x.x, reinstall shall be required.

[gregorypratt]

This solved it for me:

npm uninstall node-sass
"node-sass": "^2.0.1" < in package.json
sudo npm update < in project

[goodforenergy]

Thanks @StoneCypher. @am11 Yes, definitely a heisenbug, haha! Thanks for your suggestions, I'll keep them in mind if it crops up again.

[wangxiao]

After upgrading the node node to 0.12.0, I met the same problem.

grunt server

Loading "sass.js" tasks...ERROR
>> Error: `libsass` bindings not found. Try reinstalling `node-sass`?

[am11]

@apfelbox, run these commands: https://gist.github.com/am11/e5de3c49c219f0811e1d#comment-1386582 and make a similar gist with your output.

[luozhihua]

@wangxiao same!

[wangxiao]

@luozhihua Reinstall node 0.11.9 will work.

[luozhihua]

@wangxiao Thanks, run this commands in the directory will work too: npm rebuild node-sass

[alexhidalgo]

@luozhihua rebuild worked for me!

[materliu]

@luozhihua rebuild worked for me too, thx !

[StoneCypher]

There is no need to email all these people with "this also worked for me."

[wangxiao]

Maybe Github need a "like" feature.

[materliu]

yeah, It will be convenient for us to find the right answer quickly and not disturb the most project watchers.

[am11]

@palimpsests, can you test with v3.0.0-pre?

[xtianus79]

what the heck kind of error is this. it won't go away
is this perhaps related to grunt-sass?

[luozhihua]

@xtianus79 Run this commands in the directory will work: npm rebuild node-sass

[xtianus79]

what's odd about it is that I am using Visual studio to run my project's bower... and Npm packages... now when I rebuild in my CLI which is to the folder everything works... but then VS doesn't work. When I rebuild to VS then that works and now my CLI folder doesn't work when using git bash

[am11]

@xtianus79, make sure VS2015-preview and git bash are using same npm minor versions.

[xtianus79]

@am11 do yo mean for the node-sass package? because they should be exactly the same as I put them in....

[xtianus79]

and the only reason why they are there is because VS build and places the npm packages in

[am11]

Sorry I mean node.js version, not npm.

[xtianus79]

@am11 how can I find out what version of node.js version VS is using

[am11]

@xtianus79, I have no idea. I think you can find answer to such queries at http://stackoverflow.com/. Use the tag visual-studio-2015 and node.js.

[xtianus79]

Thanks. And what is the nvm thing you were showing the other day. Would that fix things?

Sent from my Windows Phone

---

From: Adeel Mujahidmailto:[email protected]
Sent: ‎3/‎18/‎2015 12:56 PM
To: sass/node-sassmailto:[email protected]
Cc: xtianus79mailto:[email protected]
Subject: Re: [node-sass] Travis Build Error: libsass bindings not found. Try reinstalling node-sass? (#532)

@xtianus79, I have no idea. I think you can find answer to such queries at http://stackoverflow.com/. Use the tag visual-studio-2015 and node.js.

---

Reply to this email directly or view it on GitHub:
#532 (comment)

[am11]

nvmw, but you will still need to 'somehow' configure VS to use the preferred node.js version, instead the one which they shipped VS with..

[xtianus79]

thanks @am11 ... would you know how to do that by any chance?

[StoneCypher]

unsubscribing, even though i used to want to watch this bug

[xtianus79]

@am11 they said it is 10.31 and they would write a blog post about it tomorrow. however their solution to fix it was not clear and it didn't seem to have any affect. it always seems like this stuff is baked in.

[am11]

@xtianus79, baked-in stuff is good. But it would be nice if they let you manage which version you want to use, and even which runtime; node.js and/or io.js (which is practically node.js on steroids!).

[xtianus79]

@am11 agreed. However, it seems like they want to let you change it but it doesn't seem to actually work. Kind of the like the secret .gitignore file... which I figure the secret file was there because when i coped another one into the path it changed it to -copy... lol

[xtianus79]

@am11 totally fixed my issue with your help and Mads blog post he released today...
http://blogs.msdn.com/b/webdev/archive/2015/03/19/customize-external-web-tools-in-visual-studio-2015.aspx

For anyone looking to have your path setup correctly to use PS - make sure ruby, and git, NPM, and Ruby are in your path...

[xtianus79]

@luozhihua you're suggestion finally worked but the conflict was VS Vnext was using a baked in node 0.10.31 version and I have 0.12.0 installed on my path.

[am11]

@xtianus79, good to know and thanks for sharing the blog link. 👍
Meaning we can make it work with io.js as well!

[xtianus79]

oh no you are going to make me look at another thing. lol... after my build. are you interested in getting my framework into omni aspnet generator???

[JoshMcCullough]

FYI for those having this issue when using VS2015, you have to install the same version of node which VS is using (0.10.31 32bit currently: https://nodejs.org/dist/v0.10.31/node-v0.10.31-x86.msi). More info here: http://stackoverflow.com/questions/31301582/task-runner-explorer-cant-load-tasks/31304060#31304060

[am11]

@JoshMcCullough, thanks for the info! But isn't it so that @madskristensen's blog post pointed out by @xtianus79 (http://blogs.msdn.com/b/webdev/archive/2015/03/19/customize-external-web-tools-in-visual-studio-2015.aspx) explains how user can change the default node.js (-like) runtimes (node.js/io.js/atom-shell etc.)? Which means you can install a latest (or your favourite) version of node.js or io.js and point VS2015 to use it for task-runner.

[saper]

You should have your node engine and your node-sass binding compiled against the same C++ runtime library. You can use VS's built-in node or tell VS to use another engine, does not matter. Just use the same for all binary modules.

[JoshMcCullough]

Cool, I'd LOVE to use the non-built-in version of node, and will check that link! Thanks.

[JoshMcCullough]

This worked great, thanks @am11!

[xzyfer]

Is any of this worth adding to the troubleshooting guide?
On 11 Jul 2015 06:50, "Josh McCullough" [email protected] wrote:

This worked great, thanks @am11 https://github.com/am11!

—
Reply to this email directly or view it on GitHub
#532 (comment).

[am11]

Is any of this worth..

Implicitly yes.

Swell Story:

Given Sass editor (OOTB) support was first added in VS2013 (Update 3? or 2?), and mostly people who were using Sass with VS2013 had Web Essentials 2013 extension installed. WE2013 packs node.exe with CSS/JS superset compiler packages including node-sass and hence distill the version of node-sass binary (binding.dll->binding.node).
With VS2015, "task runner" is a first class citizen of IDE. While MSBuild is responsible for building the backend code, Task Runner lets user configure the front-end build system of their choice (Bower, Grunt, Gulp etc.) and build the front-end artifacts at solution build time. Therefore WE2015 dropped all the packaging and manifesting of node.js runtime & packages in favour of out-of-the-box task runner support and focuses on enhancing the editor functionality (preview window etc.). While other extensions like (https://github.com/madskristensen/NpmTaskRunner) extend on task runner capabilities to provide more node-y stuff.

With that said, it may confuse the user of VS2013, who upgraded to VS2015, if they install node-sass with system-installed node.exe or copy from other machine and then expect it to run via task runner (like for example they can do with coffeescript or less packages). Since (as we know and some users may not.. that) node-sass is based on native (C++) binary and the binary downloaded at install-time is specific to that version of node.exe, OS bitness/arch etc., it is not as "portable" as other npm packages.

So a short version of this story would probably save us from explaining it over and again. 😉

[xzyfer]

I look forward to your pull request @am11 :D
On 11 Jul 2015 10:47, "Adeel Mujahid" [email protected] wrote:

Is any of this worth..

Implicitly yes.

Swell Story:

Given Sass editor (OOTB) support was first added in VS2013 (Update 3? or
2?), and mostly people who were using Sass with VS2013 had Web Essentials
2013 extension installed. WE2013 packs node.exe with CSS/JS superset
compiler packages including node-sass and hence distill the version of
node-sass binary (binding.dll->binding.node).
With VS2015, "node runtime" is a first class citizen of IDE. While MSBuild
is responsible for building the backend code, Task Runner les user
configure the front-end build system of their choice (Bower, Grunt, Gulp
etc.) and build the front-end artifacts at build time. Therefore WE2015
dropped all the packaging and manifesting of node.js runtime & packages in
favour of out-of-the-box task runner support and focuses on enhancing the
editor functionality (preview window etc.). While other extensions like (
https://github.com/madskristensen/NpmTaskRunner) extend on task runner
capabilities to provide more node-y stuff.

With that said, it may confuse the user of VS2013, who upgraded to VS2015,
if they install node-sass with system-installed node.exe or copy from other
machine and then expect it to run via task runner (like coffeescript or
less packages). Since (as we know and some users may not.. that) node-sass
is based on native (C++) binary and the binary downloaded at install-time
is specific to that version of node.exe, OS bitness/arch etc., it is not as
"portable" as other npm packages.

So a short version of this story would probably save us from explaining it
over and again. [image: 😉]

—
Reply to this email directly or view it on GitHub
#532 (comment).