yarnpkg/yarn

Installing node-sass and rebuilding/using it results in module not found

aouaki opened this issue Β· 35 comments

Hello,

Do you want to request a feature or report a bug?
Bug

What is the current behavior?

I install node-sass@^3.13.0 using yarn 0.17.8. I then run npm rebuild node-sass and it outputs :
Error: Cannot find module 'sax'
The missing is sometimes different (happened to be has too).

It also happens without running npm rebuild node-sass. When using node-sass without rebuilding it, I encounter the same error.

Logs

$ npm rebuild node-sass@^3.13.0
       
       > node-sass@3.13.0 install /tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/node-sass
       > node scripts/install.js
       
       node-sass build Binary found at /tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/node-sass/vendor/linux-x64-51/binding.node
       
       > node-sass@3.13.0 postinstall /tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/node-sass
       > node scripts/build.js
       
       Binary found at /tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/node-sass/vendor/linux-x64-51/binding.node
       Testing binary
       Binary is fine
       node-sass@3.13.0 /tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/node-sass
       Error: Cannot find module 'sax'
       at Function.Module._resolveFilename (module.js:472:15)
       at Function.Module._load (module.js:420:25)
       at Module.require (module.js:500:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/svgo/lib/svgo/svg2js.js:3:11)
       at Module._compile (module.js:573:32)
       at Object.Module._extensions..js (module.js:582:10)
       at Module.load (module.js:490:32)
       at tryModuleLoad (module.js:449:12)
       at Function.Module._load (module.js:441:3)
       at Module.require (module.js:500:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/svgo/lib/svgo.js:14:14)
       at Module._compile (module.js:573:32)
       at Object.Module._extensions..js (module.js:582:10)
       at Module.load (module.js:490:32)
       at tryModuleLoad (module.js:449:12)
       at Function.Module._load (module.js:441:3)
       at Module.require (module.js:500:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/postcss-svgo/dist/index.js:15:13)
       at Module._compile (module.js:573:32)
       at Object.Module._extensions..js (module.js:582:10)
       at Module.load (module.js:490:32)
       at tryModuleLoad (module.js:449:12)
       at Function.Module._load (module.js:441:3)
       at Module.require (module.js:500:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_018b7933b66e2c3d195b746872072c52/node_modules/cssnano/dist/index.js:37:20)
       at Module._compile (module.js:573:32)
       error Command failed with exit code 1.
       info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

Versions :
OS: Heroku VM using yarn node.js buildpack (https://github.com/heroku/heroku-buildpack-nodejs/tree/yarn)
yarn: 0.17.8
node-sass: 3.13.0
npm: 3.10.9
node: LTS and latest tried

Could be related to sass/node-sass#1804 but on this issue they say it's fixed on yarn v0.17.7, while on 0.17.8 it isn't for me.

Thanks,
Arthur

Installing with yarn and then rebuilding with npm doesn't seem like a good idea to me.

I have tried the following snippet in both macOS & Ubuntu and it's working using yarn v0.17.8.

var sass = require('node-sass');
sass.render({
  file: 'test.scss'
}, function(err, result) {
  result && console.log(result);
});

So, I would suggest you to do a yarn add --force node-sass instead of npm rebuild node-sass

I can confirm that node-sass on Yarn v0.17.8 is breaking my CI at the moment. I haven't yet updated Yarn on my own machine (still on v0.17.6).

Running yarn add --force node-sass instead of npm rebuild node-sass works but then my webpack script has the same module issue when running node-sass to compile the scss files:

       $ webpack --config webpack/webpack.prod.js --bail
       Error: Cannot find module 'sax'
       at Function.Module._resolveFilename (module.js:472:15)
       at Function.Module._load (module.js:420:25)
       at Module.require (module.js:500:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_180a33712e5aeecf19bea94b2918467c/node_modules/svgo/lib/svgo/svg2js.js:3:11)
       at Module._compile (module.js:573:32)
       at Object.Module._extensions..js (module.js:582:10)
       at Module.load (module.js:490:32)
       at tryModuleLoad (module.js:449:12)
       at Function.Module._load (module.js:441:3)
       at Module.require (module.js:500:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_180a33712e5aeecf19bea94b2918467c/node_modules/svgo/lib/svgo.js:14:14)
       at Module._compile (module.js:573:32)
       at Object.Module._extensions..js (module.js:582:10)
       at Module.load (module.js:490:32)
       at tryModuleLoad (module.js:449:12)
       at Function.Module._load (module.js:441:3)
       at Module.require (module.js:500:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_180a33712e5aeecf19bea94b2918467c/node_modules/postcss-svgo/dist/index.js:15:13)
       at Module._compile (module.js:573:32)
       at Object.Module._extensions..js (module.js:582:10)
       at Module.load (module.js:490:32)
       at tryModuleLoad (module.js:449:12)
       at Function.Module._load (module.js:441:3)
       at Module.require (module.js:500:17)
       at require (internal/module.js:20:19)
       at Object.<anonymous> (/tmp/build_180a33712e5aeecf19bea94b2918467c/node_modules/cssnano/dist/index.js:37:20)
       at Module._compile (module.js:573:32)
       error Command failed with exit code 1.

@aouaki, can you run yarn cache clean, does it help?

@bestander Doesn't change anything 😞. I don't think that heroku's deployments use yarn's cache anyway. @hassankhan do you still have the issue ?

Haven't yet had the chance to update Yarn and check, will do later today and report back

I'm facing the same issue when deploying to Heroku.

I'm using yarn 0.18.1. I declare that in the "engines" section of package.json, which Heroku honors.

``` remote: -----> Installing binaries remote: engines.node (package.json): 6.3.0 remote: engines.npm (package.json): unspecified (use default) remote: remote: Downloading and installing node 6.3.0... remote: Using default npm version: 3.10.3 remote: Downloading and installing yarn (0.18.1)... remote: Installed yarn 0.18.1 ```

The first build after clearing Heroku's build cache succeeds. Further builds fail to compile my SASS stylesheets with webpack beacuse node-sass fails to find the vendor directory.

``` remote: ERROR in ./amalfi/documents/main.sass remote: Module build failed: ModuleBuildError: Module build failed: Error: ENOENT: no such file or directory, scandir '/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/node-sass/vendor' remote: at Error (native) remote: at Object.fs.readdirSync (fs.js:951:18) remote: at Object.getInstalledBinaries (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/node-sass/lib/extensions.js:122:13) remote: at foundBinariesList (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/node-sass/lib/errors.js:20:15) remote: at foundBinaries (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/node-sass/lib/errors.js:15:5) remote: at Object.module.exports.missingBinary (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/node-sass/lib/errors.js:45:5) remote: at module.exports (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/node-sass/lib/binding.js:15:30) remote: at Object. (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/node-sass/lib/index.js:14:35) remote: at Module._compile (module.js:541:32) remote: at Object.Module._extensions..js (module.js:550:10) remote: at Module.load (module.js:458:32) remote: at tryModuleLoad (module.js:417:12) remote: at Function.Module._load (module.js:409:3) remote: at Module.require (module.js:468:17) remote: at require (internal/module.js:20:19) remote: at Object. (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/sass-loader/index.js:4:12) remote: at Module._compile (module.js:541:32) remote: at Object.Module._extensions..js (module.js:550:10) remote: at Module.load (module.js:458:32) remote: at tryModuleLoad (module.js:417:12) remote: at Function.Module._load (module.js:409:3) remote: at Module.require (module.js:468:17) remote: at require (internal/module.js:20:19) remote: at loadLoader (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/loadLoader.js:13:17) remote: at iteratePitchingLoaders (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:164:2) remote: at iteratePitchingLoaders (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:160:10) remote: at /tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:168:18 remote: at loadLoader (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/loadLoader.js:36:3) remote: at iteratePitchingLoaders (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:164:2) remote: at runLoaders (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:357:2) remote: at /tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/NormalModule.js:143:35 remote: at /tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:359:11 remote: at /tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:165:18 remote: at loadLoader (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/loadLoader.js:27:11) remote: at iteratePitchingLoaders (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:164:2) remote: at iteratePitchingLoaders (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:160:10) remote: at /tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:168:18 remote: at loadLoader (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/loadLoader.js:36:3) remote: at iteratePitchingLoaders (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:164:2) remote: at runLoaders (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/loader-runner/lib/LoaderRunner.js:357:2) remote: at NormalModule.doBuild (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/NormalModule.js:131:2) remote: at NormalModule.build (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/NormalModule.js:182:15) remote: at Compilation.buildModule (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/Compilation.js:129:9) remote: at Compilation. (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/Compilation.js:406:8) remote: at /tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/NormalModuleFactory.js:243:4 remote: at /tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/NormalModuleFactory.js:94:13 remote: at /tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/tapable/lib/Tapable.js:168:11 remote: at NormalModuleFactory. (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/CompatibilityPlugin.js:52:4) remote: at NormalModuleFactory.applyPluginsAsyncWaterfall (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/tapable/lib/Tapable.js:172:13) remote: at onDoneResolving (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/NormalModuleFactory.js:69:11) remote: at onDoneResolving (/tmp/build_fecf70d99758306b4e17bbcbf75d69fa/node_modules/webpack/lib/NormalModuleFactory.js:190:6) remote: at _combinedTickCallback (internal/process/next_tick.js:67:7) remote: at process._tickCallback (internal/process/next_tick.js:98:9) ```

As a workaround, I added:

yarn remove node-sass
yarn add node-sass@latest

to my deployment script, after installing dependencies but before running webpack.

This allows me to deploy my app with yarn, but negates most of the speed advantage of yarn over npm (it feel like 3 x 15 seconds instead of 1 x 45 seconds β€” I didn't time it precisely).

I came across multiple reports of this issue in the node-sass and yarn repositories. Maintainers of node-sass believe it's a bug in yarn.

It would be useful to consolidate discussions in one issue, in the repository of the project where the fix belongs.

kjs3 commented

@aaugustin: Did you run…

yarn remove node-sass
yarn add node-sass@latest

…in postinstall, heroku-postbuild, or some other hook?

I added it in bin/post_compile in my project.

I'm not relying on Heroku's automatic build hooks, I'm doing everything manually in bin/post_compile, notably because I apply some patches before compiling my app.

Hope this helps!

Same issue here, while using Yarn (0.21.3). It's failing at Heroku build (node-sass error). Even the suggested workaround did not work for me (before_script: - yarn add --force node-sass). Can we get a ETA on the fix for this as Travis CI is failing at Deploy stage due to Heroku build failure. Thank you.

How can we help triage/confirm this? I can easily reproduce this using Travis CI and CircleCI.

It looks like a node_modules cache issue within Heroku while using Yarn. When I set the config vars in Heroku to disable cache for node_modules, the build and the deployment went through fine. Not sure, how long will we need to keep clearing node_modules cache while using Yarn.

It's not specific to Heroku. We had to deploy workarounds on Travis CI and CircleCI. I also had it fail locally at least once when upgrading but that's not trivial to replicate.

I can confirm this affects Docker as well. I'm using yarn 0.21.3. Including the remove/add workaround in my startup script solves the problem.

Can anyone provide a clear repro step with latest version of Yarn?

I encountered same problem on yarn 0.22.0...
I guess, node-sass's vendor dir is removed on linking packages step when there is changes of yarn.lock.

Same issue here on 0.23, every time I run yarn I need to run npm rebuild node-sass for the latter to work

Getting this to work on Heroku and CircleCI just now, we had to do two things:

add this to npm's package.json

{
  "scripts": {
    "postinstall": "npm rebuild node-sass"
  }
}

add this to Heroku's app.json

{
  "env": {
    "NODE_MODULES_CACHE": "false",
  }
}

And just an observation that I would've found helpful to read earlier:
node-sass seems to work on any first build (like on Heroku: creating a new branch & PR, which creates a new PR app), but not on any subsequent builds (like when pushing to that branch a 2nd time, triggering another Heroku deploy git commit --allow-empty -m "redeploy"). This makes sense given what's in this thread, but I didn't think of it on my own at the time. I falsely believed that I'd fixed this issue by [updating my yarn.lock on a PR app] lol - but nope!

holm commented

We have this problem also on both Circle CI and Heroku. It removes native builds on second installs. It seems to be related to changes to the yarn.lock file. I have tried to create a test case to replicate, but have not been able to, despite trying quite a bit.

It also seems to be the same issue a few other places, if that helps:

Pretty sure I know the cause of this. Yarn is saving all known build artifacts to our internal cache. Heroku and others would just be caching node_modules and restoring that, since we don't have our original Yarn cache we don't know the possible artifacts.

Opened #3224 which might fix this.

Thanks @kittens, I'm happy to see you are on getting us a solution. I too am having the same issue on heroku. Initial heroku deploy of the app worked fine. Once the project was updated I continue to get this error:

Error: ENOENT: no such file or directory, scandir '/app/node_modules/node-sass-middleware/node_modules/node-sass/vendor'
I will use above work around until issue is solved.

I can confirm that 0.23.3 solved the issue. Thanks @kittens !

We're still getting this issue on two of our apps (using yarn 0.23.3), and I've had to add back in this line again:

"postinstall": "npm rebuild node-sass"

(It seemed to work for some builds for a while, maybe it happened again when we updated packages or something?)

This unfortunately seemed to only temporarily fix the issue for us also. @bestander perhaps this should be reopened? Or should we create a new issue?

I'm seeing this issue with v0.24.5 and bcrypt - different package, same problem.

I am using Yarn v0.24.6 and it has the same issue with node-sass rebuilding, as described here.

I still see this on Heroku today after making the move from npm to yarn.

This issue has got even worse since I think v0.24.6, now it ruins node-sass every time I add a new library to the project. This is happening to me and other people in my team on different projects. I will try to find some time to investigate or at least create a reproducible example.

@bestander apologizes, seems that the bug I found is a mixture of Yarn bug and user behaviour and it might be completely unrelated to this issue. I have created a separate issue - #3752 - but since it's necessary for the user to make a mistake first, I'd say it's definitely lower priority than I initially suspected :)

Sorry for the extra noise!

yarn add --force node-sass can install newer version of node-sass. It's better just to rm -rf ./node_modules and yarn install again.

yarn add --force node-sass still tries to install all of my other packages in package.json and would fail. If I npm rebuild node-sass it works but then yarn doesn't use it. yarn upgrade node-sass worked for me though.