Skip to content
This repository has been archived by the owner on Jul 24, 2024. It is now read-only.

Constantly have to rebuild node-sass #1918

Closed
mikecfisher opened this issue Mar 6, 2017 · 25 comments
Closed

Constantly have to rebuild node-sass #1918

mikecfisher opened this issue Mar 6, 2017 · 25 comments

Comments

@mikecfisher
Copy link

Hi all, I'm having difficulties working with node-sass. I'm using it via the sass-loader in Webpack 2. Every other day when running webpack to compile my app. I'm getting this error below.

ERROR in /phoenix-wallet/~/css-loader!/phoenix-wallet/~/resolve-url-loader!/Users/e063428/Dev/Mastercard/phoenix-wallet/~/sass-loader/lib/loader.js?{"sourceMap":true}!./app/variants/default/styles/style.scss
Module build failed: Error: ENOENT: no such file or directory, scandir '/Users/e063428/Dev/Mastercard/phoenix-wallet/node_modules/node-sass/vendor'
    at Error (native)

The only thing that solves this error is running npm rebuild node-sass this phenomenon is happening on my machine as well as many of my coworkers. All of us have slightly different node environments as well although we're all using yarn as our package manager.

  • Yarn version (0.20.3):
  • Node version (6.10.0):
  • Node Process::
 http_parser: '2.7.0',
  node: '6.10.0',
  v8: '5.1.281.93',
  uv: '1.9.1',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  icu: '58.2',
  modules: '48',
  openssl: '1.0.2k' }
  • Node Platform (darwin):
  • Node architecture (x64):
  • node-sass version:
node-sass	4.5.0	(Wrapper)	[JavaScript]
libsass  	3.5.0.beta.2	(Sass Compiler)	[C/C++]
  • npm node-sass versions (4.5.0):
@xzyfer
Copy link
Contributor

xzyfer commented Mar 6, 2017

There are a lot of known issue with yarn, as a result we cannot officially support it. Please try using to npm to see if the issue persists. If it does not please open an issue with yarn.

@skylarmb
Copy link

skylarmb commented Mar 6, 2017

Same problem. My solution is just to run npm rebuild node-sass as a post-install script. So annoying, especially when building on CI.

@xzyfer
Copy link
Contributor

xzyfer commented Mar 6, 2017

@skylarmb are you also using yarn? If so please try npm.

@skylarmb
Copy link

skylarmb commented Mar 6, 2017

@xzyfer yes we use yarn. We have no plan to use npm until the day it utilizes a lockfile like yarn does. For now just running npm rebuild node-sass after yarn install will have to do.

@xzyfer
Copy link
Contributor

xzyfer commented Mar 7, 2017

@skylarmb I understand. I'm simply asking if you can confirm the problem doesn't exist with npm so we can confirm it's a yarn issue.

@adambratt
Copy link

Also having this issue, quite curious as to why this is the only package that I have this issue with when using yarn.

@brandonaaskov
Copy link

brandonaaskov commented Mar 22, 2017

At the risk of saying this too soon, I think #1185 fixes this (in release 4.5.1). I was using an older version, but since upgrading this hasn't cropped up. Not that I've had extensive time to test it as that release came out 13 hours ago :)

UPDATE: I was far too hopeful and eager there. Still running npm rebuild node-sass all the time.

@tiendq
Copy link

tiendq commented Mar 30, 2017

Every time I add/remove a package with Yarn, then I have to run npm rebuild node-sass again. Very annoyed.

yarn 0.21.3 on macOS

@nschonni
Copy link
Contributor

Closing since the general yarn issues are tracked in #1804

@hod-shcraigen
Copy link

I frequently have this issue, and I don't use yarn, therefore I would suggest that the ticket is closed prematurely and may not be yarn specific.

@hod-shcraigen
Copy link

`Error: Missing binding /Library/WebServer/Documents/hod/pttg-sprint/node_modules/node-sass/vendor/darwin-x64-51/binding.node
Node Sass could not find a binding for your current environment: OS X 64-bit with Node.js 7.x

Found bindings for the following environments:

  • OS X 64-bit with Node.js 4.x

This usually happens because your environment has changed since running npm install.
Run npm rebuild node-sass to build the binding for your current environment.
at module.exports (/Library/WebServer/Documents/hod/pttg-sprint/node_modules/node-sass/lib/binding.js:15:13)
at Object. (/Library/WebServer/Documents/hod/pttg-sprint/node_modules/node-sass/lib/index.js:14:35)
at Module._compile (module.js:571:32)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)
at Module.require (module.js:498:17)
at require (internal/module.js:20:19)
at Object. (/Library/WebServer/Documents/hod/pttg-sprint/node_modules/gulp-sass/index.js:187:21)`

@xzyfer
Copy link
Contributor

xzyfer commented May 4, 2017 via email

@hod-shcraigen
Copy link

@xzyfer thanks, but I don't switch between node versions, I'm always in node 7.x when I have to rebuild node-sass and it's never very long before it complains of the same issue again. Is there something different about this module compared to with others? This is the only npm module that asks to be rebuilt.

@xzyfer
Copy link
Contributor

xzyfer commented May 4, 2017 via email

@saper
Copy link
Member

saper commented May 7, 2017

@hod-shcraigen as @xzyfer said, it is clear what is happening.

Can you provide the output of the troubleshooting commands as the OP did?

Do you have nvm installed?

If nothing explains, just scan you whole filesystem with something like "find / -name node -print -exec {} -v" (haven't tested) and see where your different node engines come from.

@dydFreeman
Copy link

I'm working with Visual Studio 2017 and the only way to fix that error was to change the "External Web Tools" config:

image

In this way you're forcing VS to use the Node present in your env path and not the VS's one.

@nolongerinuse
Copy link

Building with CI this is frustrating compiling for every deployment. Is it possible to install and compile it when I build my docker image? Is it possible to install node-sass globally and compile it, so my deployments don't require a build from scratch?

@xzyfer
Copy link
Contributor

xzyfer commented Aug 21, 2017 via email

@johanchouquet
Copy link

johanchouquet commented Sep 13, 2017

Hey, i have the same problem. I wondered: as we all know our target environments (linux docker container, for me), i'd like to be able to download the package directly, then copy it into /node_modules folder. That way, when we build our images, we could do it only once, then it'd get cached, then, we move on.

@roboto84
Copy link

roboto84 commented Oct 6, 2017

I wonder if this issue should be re-opened with the amount of people that are experiencing it. I also ended up here after I attempted to upgrade from node v7.10.1 to node v8.6.0 with npm v5.3.0. Now on every npm install (after clearing the node modules folder) it seems libsass has to get rebuilt. Strange how it only seems to be an issue after the upgrade.

UPDATE: Sorry for the noise, my issue was solve by updating to the latest node-sass (4.5.3) and with that I was able to DL the pre-built version, should have tried to do that first. I have always used npm though, can't speak for yarn folks.

npm install

> [email protected] install /Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/fsevents
> node install

[fsevents] Success: "/Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/fsevents/lib/binding/Release/node-v57-darwin-x64/fse.node" already installed
Pass --update-binary to reinstall or --build-from-source to recompile

> [email protected] install /Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/node-sass
> node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v3.13.1/darwin-x64-57_binding.node
Cannot download "https://github.com/sass/node-sass/releases/download/v3.13.1/darwin-x64-57_binding.node": 

HTTP error 404 Not Found

Hint: If github.com is not accessible in your location
      try setting a proxy via HTTP_PROXY, e.g. 

      export HTTP_PROXY=http://example.com:1234

or configure npm proxy via

      npm config set proxy http://example.com:8080

> [email protected] install /Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/phantomjs-prebuilt
> node install.js

PhantomJS not found on PATH
Download already available at /var/folders/n1/n8pn2dfn2t37x5jqt4gfzf7m0000gn/T/phantomjs/phantomjs-2.1.1-macosx.zip
Verified checksum of previously downloaded file
Extracting zip contents
Removing /Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/phantomjs-prebuilt/lib/phantom
Copying extracted folder /var/folders/n1/n8pn2dfn2t37x5jqt4gfzf7m0000gn/T/phantomjs/phantomjs-2.1.1-macosx.zip-extract-1507293146791/phantomjs-2.1.1-macosx -> /Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/phantomjs-prebuilt/lib/phantom
Writing location.js file
Done. Phantomjs binary available at /Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/phantomjs-prebuilt/lib/phantom/bin/phantomjs

> [email protected] postinstall /Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/node-sass
> node scripts/build.js

Building: /Users/momo/.nvm/versions/node/v8.6.0/bin/node /Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/node-gyp/bin/node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=
gyp info it worked if it ends with ok
gyp verb cli [ '/Users/momo/.nvm/versions/node/v8.6.0/bin/node',
gyp verb cli   '/Users/momo/Documents/Apps/front-end/JanusReboot/janus-ui/node_modules/node-gyp/bin/node-gyp.js',
gyp verb cli   'rebuild',

Cut off output after gyp verb cli 'rebuild' as it just continues to build libsass. Did note https://github.com/sass/node-sass/releases/download/v3.13.1/darwin-x64-57_binding.node doesn't lead to anything, so not sure if that may be an issue.

@shcallaway
Copy link

My team uses volumes to serve code from macOS into an Ubuntu-based Docker environment. To make sure we have the correct node-sass binary, we run this script as a pre-build hook:

var exec = require('child_process').exec;

function verify() {
  const os = process.platform.toLowerCase();
  console.log(`[verify-sass] Your operating system: ${os}`);
  return new Promise((resolve, reject) => {
    exec(`test -d ./node_modules/node-sass/vendor/${os}*`).on('exit', resolve);
  });
}

function rebuild() {
  return new Promise((resolve, reject) => {
    exec('npm rebuild node-sass --force').on('exit', resolve);
  });
}

console.log('[verify-sass] Verifying correct node-sass binary exists.');
verify().then((exitCode) => {
  if (exitCode) {
    console.log('[verify-sass] Binary missing for this OS!');
    console.log('[verify-sass] Running \'npm rebuild node-sass --force\'.');
    console.log('[verify-sass] This may take a moment...');
    rebuild().then(() => {
      console.log('[verify-sass] Finished!');
    });
  } else {
    console.log('[verify-sass] Verified!');
  }
});

Hope it helps!

@aagentah
Copy link

aagentah commented Nov 8, 2017

Having the same issue, any updates?
Running npm rebuild node-sass prior to yarn works fine.

@wy193777
Copy link

wy193777 commented Dec 20, 2017

Same here.

Upgrade node-sass and other dependent packages fix the problem.

kontrollanten added a commit to hitta-skyddsrum/webclient-preact that referenced this issue Jan 14, 2018
@archonic
Copy link

For anyone else having this problem with Docker and Docker Compose on Mac OS X, here's how I solved it.

You can solve the problem once per run by running docker-compose exec webpacker npm rebuild node-sass --force where webpacker is the name of webpacker service. This will create the linux binary for node-sass in /node_modules/node-sass/vendor/{your-docker-os}. Restarting the container however destroys the read-write layer on top of your mounted volume, and the error will come up again.

To solve the issue permanently (or at least until you change things), copy the docker os node-sass binary to your application, so that the volume has it on startup. After running the webpacker container, and running docker-compose exec webpacker npm rebuild node-sass --force, copy the binary to your local filesystem with docker cp namespace_webpacker_1:/app/node_modules/node-sass/vendor/{your-docker-os}/binding.node /Users/{youruser}/{yourapp}/node_modules/node-sass/vendor/{your-docker-os}/

Another easier way to solve this permanently is ensuring your webpacker service mounts your app in it's volume. You could then skip the docker cp command. This is what my webpacker service looks like in docker-compose.yml

  webpacker:
    build: .
    env_file:
      - '.env'
    command: ./bin/webpack-dev-server --inline true
    volumes:
      - '.:/app'
    ports:
      - '3035:3035'

Hope that helps.

@sass sass deleted a comment from gkatsanos Jan 19, 2018
@sass sass deleted a comment from gkatsanos Jan 19, 2018
@sass sass deleted a comment from danechitoaie Jan 19, 2018
@sass sass deleted a comment from shtse8 Jan 19, 2018
@sass sass deleted a comment from gkatsanos Jan 19, 2018
@sass sass deleted a comment from VinceOPS Jan 19, 2018
@sass sass deleted a comment from akella Jan 19, 2018
@sass sass deleted a comment from skylarmb Jan 19, 2018
@xzyfer
Copy link
Contributor

xzyfer commented Jan 19, 2018

This issue is reference very old versions of node-sass, and bugs that have since been fixed in yarn and npm. Please open a new issue if you are encounter similar problems.

@sass sass locked and limited conversation to collaborators Jan 19, 2018
jiongle1 pushed a commit to scantist-ossops-m2/node-sass that referenced this issue Apr 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests