node-sass: Failed at the node-sass@2.0.1 postinstall script 'node scripts/build.js'

Hi,

npm tell me to report you this bug, here is the log file, but it’s very long, maybe you prefer only just the error:

Error: Error relocating /home/project/project-front/node_modules/gulp-sass/node_modules/node-sass/vendor/linux-x64-node-0.10/binding.node:
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/home/project/project-front/node_modules/gulp-sass/node_modules/node-sass/lib/index.js:188:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)

OS: alpine linux kernel: Linux 3.14.36-0-grsec npm: 2.7.3 nodejs: v0.10.33

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 25 (10 by maintainers)

Most upvoted comments

Strange… I had a lot of trouble getting this to work yesterday. There must have been an old version of the npm cache (or something) that bit me, this worked perfectly today! I also though semver acted that way, but the @beta did work, ^3.4.2 did not. I must have overlooked something…

Lots of output truncated

localhost { ~ }$ docker run -it --rm alpine:3.3 sh
/ # apk update
/ # apk add nodejs python make g++
/ # npm install node-sass sass-loader
/ # npm list node-sass sass-loader
/
├── node-sass@3.6.0
└── sass-loader@3.2.0

Everything is good! Thanks!

xeor on Apr 26, 2016

@shouze, our binary building is party automated. For Windows, all bins are built on AppVeyor CI, then we download the artifacts and upload them as release assets manually. For Linux, we build on CentOS for maximum compatibility. At some point we were using this Docker script https://gist.github.com/am11/1529b2458b1a1f4bdba8 which produces all variants of binaries (arch x node.js module versions). We can potentially compile against musl by having a similar docker recipe.

Furthermore, it would also require some alteration in our binary naming convention to disambiguate varied C-runtimes: https://github.com/sass/node-sass/blob/a04e84d/lib/extensions.js#L171. For instance, something to let both linux-ia32-44_binding.node and linux-musl-ia32-44_binding.node co-exist. At runtime or during the installation, we can detect it by checking whether the output of require('os').release() contains “musl” or “alpine”.

am11 on May 30, 2016