[0.24.5] Issues with node-sass #3485

jklmli · 2017-05-23T19:40:27Z

What is the current behavior?
node-sass, and other libraries with build artifacts, occasionally fail at runtime when installed with yarn. The workaround is to run npm rebuild node-sass after doing a yarn update.

If the current behavior is a bug, please provide the steps to reproduce.

Quoting a post on the same issue from 0.17.0:

How to reproduce consistently:

CircleCI 2.0 Docker program.

Create your project as is with a package.json. Create yarn lock file via yarn install/upgrade.

Add node-sass or gulp-sass into project (Currently testing with gulp-sass)

Ensure proper tokens are hooked into repository to allow webhooks for CircleCI

Ensure project is configured to use CircleCI Beta 2.0 (Apply on their website)

Add the following into .circleci/config.yml.

Check in code.

The first run, the docker container will be built, no cache will exist, yarn will run an install, and then perform a successful compilation of sass using gulp-sass. It will succeed.

Do another noop checkin. The following build will use the cache saved from the previous successful run, restore the cache, and then run a yarn install which will be very quick because cache has been restored. The next compilation command (the SASS/SCSS), will now consistently fail with:
yarn run css
yarn run v0.23.4
$ gulp css
fs.js:914
  return binding.readdir(pathModule._makeLong(path), options.encoding);
                 ^

Error: ENOENT: no such file or directory, scandir '/root/project/node_modules/node-sass/vendor'
./.circleci/config.yml
version: 2
jobs:
  build:
    working_directory: ~/project
    
    docker:
      - image: node:7.10

    steps:
      - checkout
      - restore_cache:
          key: deps-{{ .Branch }}-{{ checksum "yarn.lock" }}
      - run:
          command: yarn install --pure-lockfile --no-progress
      - save_cache:
          key: deps-{{ .Branch }}-{{ checksum "yarn.lock" }}
          paths:
            - node_modules
# ADD THIS COMMAND HERE THAT USES NODE-SASS / GULP-SASS
#      - run:
#          command: yarn run css  
Refs:

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

What is the expected behavior?
node-sass shouldn't need to be rebuilt via npm rebuild after an install/update. npm doesn't require a rebuild when installing it.

Please mention your node.js, yarn and operating system version.
node 6.10.2
yarn 0.24.5
mac 10.12.5

Closing notes
This was tackled in 0.24.0 via #3224, but there looks to be outstanding issues.

This also affects other libraries - any library with artifacts - including karma-phantomjs-launcher.

The text was updated successfully, but these errors were encountered:

bestander · 2017-05-24T15:40:14Z

linking #3274

bestander · 2017-05-24T15:47:13Z

cc @xzyfer, who offered helping with making Yarn work with node-sass.

So, correct me if I am wrong, Yarn runs install scripts of node-sass package which generates node-sass/vendor folder.
Turns out, sometimes this folder gets deleted by Yarn?

Does anyone have a repro step?

xzyfer · 2017-05-24T16:30:03Z

I'm currently on holidays but will be back to normal activity next week. IIRC the repro is to installal node-sass, rm node_modules, and run yarn install again.

…

On 24 May 2017 5:47 pm, "Konstantin Raev" ***@***.***> wrote: cc @xzyfer <https://github.com/xzyfer>, who offered helping with making Yarn work with node-sass. So, correct me if I am wrong, Yarn runs install scripts of node-sass package which generates node-sass/vendor folder. Turns out, sometimes this folder gets deleted by Yarn? Does anyone have a repro step? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3485 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWDvbnWfs-29ngeut01nQ8dML0DQVks5r9FEOgaJpZM4NkLLh> .

acburdine · 2017-05-24T23:45:45Z

I've got a repro that I've hit 3 or 4 times in a row with the same steps.

My project uses gulp-sass, which uses node-sass, so my project doesn't depend on node-sass explicitly, but I've ran into this issue with ember-cli-sass as well on another project so I don't know if it has anything to do with sub-dependencies.

Steps:

yarn install (with no node_modules folder)
yarn add <dep> (also happens when running yarn upgrade-interactive)
Run task that uses gulp-sass
See error above
rm -rf node_modules
yarn install
gulp-sass works again.

Have hit this same error every time I've done the yarn add or yarn upgrade-interactive in recent memory.

Let me know if there's any additional info I can provide such as gulp config, package.json, or anything else 😄

bestander · 2017-05-25T10:31:31Z

Thanks!

…

On 25 May 2017 at 00:45, Austin Burdine ***@***.***> wrote: I've got a repro that I've hit 3 or 4 times in a row with the same steps. My project uses gulp-sass, which uses node-sass, so my project doesn't depend on node-sass explicitly, but I've ran into this issue with ember-cli-sass as well on another project so I don't know if it has anything to do with sub-dependencies. Steps: 1. yarn install (with no node_modules folder) 2. yarn add <dep> (also happens when running yarn upgrade-interactive) 3. Run task that uses gulp-sass 4. See error above 5. rm -rf node_modules 6. yarn install 7. gulp-sass works again. Have hit this same error every time I've done the yarn add or yarn upgrade-interactive in recent memory. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3485 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACBdWFaEmv2KuE6Mk0l3vTgHhsBqbheOks5r9MEygaJpZM4NkLLh> .

ghost · 2017-05-26T16:51:52Z

I've put the following repository together to reproduce the issue - https://github.com/destroyerofbuilds/yarn-sass

~~Developers at the company I work for actually run into the issue when using --force-lockfile, but I haven't been able to create a reproducer for that flag.~~

blimmer · 2017-05-29T23:21:10Z

@bestander I'm able to consistently reproduce this problem on the latest version of yarn (0.24.6) with these steps (also reported here):

git clone -b bug/show-issue-with-nodesass https://github.com/blimmer/ember-cli-example-app-for-github.git
cd ember-cli-example-app-for-github
yarn install --no-lockfile
DEBUG=ember-try* node_modules/.bin/ember try:one ember-lts-2.4 test --skip-cleanup

failing OSS build: https://travis-ci.org/blimmer/ember-cli-example-app-for-github/jobs/235289348

blimmer · 2017-05-30T00:01:13Z

Here's some more info after I did some investigation:

what this ember-try thing is doing is replacing the original package.json file with this diff:

diff --git a/package.json b/package.json
index 4fef7cb..63cf67b 100644
--- a/package.json
+++ b/package.json
@@ -2,9 +2,7 @@
   "name": "ember-try-test",
   "version": "0.0.0",
   "description": "The default blueprint for ember-cli addons.",
-  "keywords": [
-    "ember-addon"
-  ],
+  "keywords": ["ember-addon"],
   "license": "MIT",
   "author": "",
   "directories": {
@@ -38,7 +36,6 @@
     "ember-export-application-global": "^2.0.0",
     "ember-load-initializers": "^1.0.0",
     "ember-resolver": "^4.0.0",
-    "ember-source": "~2.13.0",
     "ember-welcome-page": "^3.0.0",
     "loader.js": "^4.2.3"
   },

From a totally clean repo, if I run:

> yarn install --no-lockfile
> ls node_modules/node-sass/vendor/darwin-x64-46
binding.node
# apply the package.json diff
> yarn install
> ls node_modules/node-sass/vendor/darwin-x64-46
gls: cannot access 'node_modules/node-sass/vendor/darwin-x64-46': No such file or directory

See how the bindings disappear there? The verbose output from the second yarn install that removes the bindings is here.

however, if I don't use --no-lockfile at first:

> yarn install
> ls node_modules/node-sass/vendor/darwin-x64-46
binding.node
# apply the package.json diff
> yarn install
> ls node_modules/node-sass/vendor/darwin-x64-46
binding.node

the file remains. verbose output from this is here.

Checking the version installed by both --no-lockfile and regular install both report the same version:

yarn list node-sass
yarn list v0.24.6
└─ node-sass@4.5.3
✨  Done in 0.98s.

Not sure if this helps, but thought I'd report what I know!

mikew · 2017-06-01T14:16:24Z

I get the error when using --pure-lockfile, I haven't tried --no-lockfile, but without any args yarn install works.

nschonni · 2017-06-01T22:45:40Z

I wonder if yarn could use the files element in package.json to figure out that there is a folder it should keep https://github.com/sass/node-sass/blob/master/package.json#L45

ghost · 2017-06-02T19:15:16Z

I updated my comment above to reflect that the issue I was originally having was not with --frozen-lockfile, but solely with --pure-lockfile.

We've been running into problems while using the NodeJS buildpack, and that buildpack uses --pure-lockfile - https://github.com/heroku/heroku-buildpack-nodejs/blob/c883f50251537f0e4cccd95749c79dd044a4357f/lib/dependencies.sh#L67

bestander · 2017-06-02T19:27:13Z

Thanks, we are looking into the issue now. A fix is coming next week

…

On Fri, 2 Jun 2017 at 20:15, Hutson Betts ***@***.***> wrote: I updated my comment above to reflect that the issue I was originally having was not with --frozen-lockfile, but solely with --pure-lockfile. We've been running into problems while using the NodeJS buildpack, and that buildpack uses --pure-lockfile - https://github.com/heroku/heroku-buildpack-nodejs/blob/c883f50251537f0e4cccd95749c79dd044a4357f/lib/dependencies.sh#L67 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3485 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACBdWHQv495IGvwoZd3YbeK-ZVSPx89dks5sAF9OgaJpZM4NkLLh> .

sth · 2017-06-14T12:51:31Z

A related ticket with steps to reproduce the issue: #3506

selfagency · 2017-06-18T18:57:53Z

I don't know if this is the right place to put this, but since updating to the latest yarn, every time I run yarn in my project's folder, which uses nvm, I have to rebuild node-sass with npm because the bindings are to my system's version of node instead of the nvm installed version my project uses.

* Update ember-cli-showdown to ^3.2.1 Eliminates build-time warning of the form "Warning: ignoring input sourcemap for vendor/showdown.js because ENOENT: no such file or directory, open '[snip]/ember-freestyle/tmp/source_map_concat-input_base_path-[random].tmp/vendor/showdown.js.map' * Lock yarn version on CI to 0.23.4 Avoids a node-sass issue with later 0.23.x versions yarnpkg/yarn#3485

There's no need to reinstall packages in the before_deploy section of the Travis build, and that second call is causing a build error due to some weirdness between Travis+node-sass+yarn+yarn cache, as described in sass/node-sass#1579 and yarnpkg/yarn#3485.

jpommerening · 2017-06-22T23:30:59Z

Ok guys, this problem bothered me for the last few days so I did some digging.

Here's what I found:

The removal of the node-sass/vendordirectory is triggered in package-linker.js, here
The possibleExtraneous files set (which the vendor dir ended up in) is populated by buildActionsForCopy and buildActionsForHardlink in util/fs.js (gloriously duplicated code btw 🙈)
There is already some logic to exclude files from being deleted but I'm not exactly sure how the artifactFiles set (the code checks this for files not to delete) is filled… maybe this would be the right place to implement what @nschonni suggested.

Also, I assume there's something that checks every file whether exists in the yarn cache and puts files into the possibleExtraneous set. (The vendor directory is not present in the cache. I believe that's correct, because caching V8 bindings would break every time someone switches node versions with nvm use.)

If it's not an option to use the files entry in the package.json, maybe yarn could record files that were created by postInstall in the yarn.lock file? I'm not familiar enough with the inner workings of yarn to go any further, maybe someone can take over? Anyway, hope this helps!

bestander · 2017-06-23T00:35:10Z

Yarn should record the files int .yarn-integrity file, something is getting lost over there I suppose.

bestander · 2017-06-23T02:09:24Z

As @destroyerofbuilds described in https://github.com/destroyerofbuilds/yarn-sass, the issue was that --pure-lockfile resulted in no .yarn-integrity file saving.
Fix is coming

bestander · 2017-06-23T02:11:14Z

Merging this issue into #3506

selfagency · 2017-06-23T04:09:52Z

I wasn't using --pure-lockfile to install anything when Yarn broke my node-sass bindings. Should I open a separate issue?

bestander · 2017-06-23T05:08:04Z

@selfagency this is another issue.
The reason is that we don't ship node-gyp with Yarn and rely on the global one.
Probably something is wrong with the paths

ghost · 2017-06-23T15:41:40Z

@bestander has merged in #3704 to resolve this issue.

Using the nightly 0.27 build (0.27.0-20170623.1327), which contains the fix, I no longer get the missing file error (Error: ENOENT: no such file or directory).

Thank you @bestander

jklmli · 2017-06-23T23:25:54Z

The original issue I filed wasn't related to #3506 - I get this issue despite using none of --pure-lockfile, --no-lockfile, or --frozen-lockfile.

Can you de-merge this from that and re-open this?

bestander · 2017-06-23T23:34:44Z

@jiaweihli to avoid confusion would you please open an issue with repro steps?

ghost · 2017-06-26T19:27:46Z

with latest

node -v
	v8.1.2
yarn --version
	0.27.0

adding latest node-gyp

yarn global add node-gyp
yarn global list
	yarn global v0.27.0
	warning package.json: No license field
	warning No license field
	info "node-gyp@3.6.2" has binaries:
	   - node-gyp

initial node-sass install is OK

yarn add --dev node-sass@^4.5
yarn list --depth 0 node-sass
	yarn list v0.27.0
	└─ node-sass@4.5.3

as is upgrade, tho it takes quite awhile 'Rebuilding all packages',

yarn upgrade node-sass@^4.5
	[4/4] Rebuilding all packages...
	success Saved lockfile.
	success Saved 0 new dependencies.
	Done in 119.06s.

I haven't yet been able to cause another similar node-sass related fail ... so far (fingers crossed)

jontelm · 2017-10-04T06:51:23Z

"npm rebuild node-sass" was a way around for now.

spullara · 2018-01-18T22:55:07Z

I also got around it with "yarn upgrade node-sass" which built it and then didn't later delete it.

See angular/angular-cli#7113. Additionally, remove no longer needed fix to yarn issue (yarnpkg/yarn#3485).

mzabuawala · 2018-03-28T12:11:31Z

@jontelm Thanks a lot, after messing around for 3 hours your suggestion worked for me.
Solution for me: "npm rebuild node-sass"

This is to get around a [yarn bug][1] which deletes breaks node-sass during the install process. [1]: yarnpkg/yarn#3485

* Port prototype Copied from https://github.com/ministryofjustice/opg-sirius-users-prototype/ * Add root-level Procfile for Heroku * Add route package.json Heroku requires there to be a package.json in the root directory * Use yarn instead of NPM * Rebuild node-sass after install This is to get around a [yarn bug][1] which deletes breaks node-sass during the install process. [1]: yarnpkg/yarn#3485 * Remove .env file * Remove docs This is just a local duplicate of [the documentation online][1] [1]: https://govuk-prototype-kit.herokuapp.com/docs/

wmadden mentioned this issue May 24, 2017

Consistent SASS theme colors adopted-ember-addons/ember-paper#693

Merged

robdimarco mentioned this issue May 25, 2017

Error on webpack:compile - Error: ENOENT: no such file or directory, scandir 'ROOT/node_modules/node-sass/vendor' rails/webpacker#422

Closed

blimmer mentioned this issue May 29, 2017

ember-try fails with default addon app + ember-cli-sass ember-cli/ember-try#126

Closed

ernscht added a commit to merkle-open/generator-nitro that referenced this issue Jun 9, 2017

fix temporary issue with yarn and node-sass (see yarnpkg/yarn#3485)

d272b42

nnashwin mentioned this issue Jun 13, 2017

ci failing, why u no sgnl/nodeku#11

Closed

bestander mentioned this issue Jun 15, 2017

feature: separate fetcher cache from poistinstall scripts artifacts cache #3642

Open

bestander added high-priority bug-install-scripts triaged labels Jun 15, 2017

simonihmig mentioned this issue Jun 18, 2017

Update ember-cli-showdown to ^3.2.1 chrislopresto/ember-freestyle#124

Merged

jseppi mentioned this issue Jun 21, 2017

rm unecessary call to yarn --pure-lockfile in before_deploy cloud-gov/pages-core#1025

Merged

bestander closed this as completed Jun 23, 2017

zuzust added a commit to adab1ts/veinapp that referenced this issue Feb 7, 2018

fix(build): fix AOT issues when building for production

42a82e9

See angular/angular-cli#7113. Additionally, remove no longer needed fix to yarn issue (yarnpkg/yarn#3485).

ashiksp mentioned this issue Nov 13, 2019

Fix CI build bigbinary/wheel#263

Closed

gregtyler added a commit to ministryofjustice/opg-sirius-user-management that referenced this issue Aug 14, 2020

Rebuild node-sass after install

a3fc48a

This is to get around a [yarn bug][1] which deletes breaks node-sass during the install process. [1]: yarnpkg/yarn#3485

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[0.24.5] Issues with node-sass #3485

[0.24.5] Issues with node-sass #3485

jklmli commented May 23, 2017 •

edited

Loading

bestander commented May 24, 2017

bestander commented May 24, 2017

xzyfer commented May 24, 2017 via email

acburdine commented May 24, 2017 •

edited

Loading

bestander commented May 25, 2017 via email

ghost commented May 26, 2017 •

edited by ghost

Loading

blimmer commented May 29, 2017 •

edited

Loading

blimmer commented May 30, 2017

mikew commented Jun 1, 2017

nschonni commented Jun 1, 2017

ghost commented Jun 2, 2017

bestander commented Jun 2, 2017 via email

sth commented Jun 14, 2017

selfagency commented Jun 18, 2017

jpommerening commented Jun 22, 2017

bestander commented Jun 23, 2017

bestander commented Jun 23, 2017

bestander commented Jun 23, 2017

selfagency commented Jun 23, 2017 •

edited

Loading

bestander commented Jun 23, 2017

ghost commented Jun 23, 2017

jklmli commented Jun 23, 2017

bestander commented Jun 23, 2017

ghost commented Jun 26, 2017

jontelm commented Oct 4, 2017

spullara commented Jan 18, 2018

mzabuawala commented Mar 28, 2018

[0.24.5] Issues with node-sass #3485

[0.24.5] Issues with node-sass #3485

Comments

jklmli commented May 23, 2017 • edited Loading

bestander commented May 24, 2017

bestander commented May 24, 2017

xzyfer commented May 24, 2017 via email

acburdine commented May 24, 2017 • edited Loading

bestander commented May 25, 2017 via email

ghost commented May 26, 2017 • edited by ghost Loading

blimmer commented May 29, 2017 • edited Loading

blimmer commented May 30, 2017

mikew commented Jun 1, 2017

nschonni commented Jun 1, 2017

ghost commented Jun 2, 2017

bestander commented Jun 2, 2017 via email

sth commented Jun 14, 2017

selfagency commented Jun 18, 2017

jpommerening commented Jun 22, 2017

bestander commented Jun 23, 2017

bestander commented Jun 23, 2017

bestander commented Jun 23, 2017

selfagency commented Jun 23, 2017 • edited Loading

bestander commented Jun 23, 2017

ghost commented Jun 23, 2017

jklmli commented Jun 23, 2017

bestander commented Jun 23, 2017

ghost commented Jun 26, 2017

jontelm commented Oct 4, 2017

spullara commented Jan 18, 2018

mzabuawala commented Mar 28, 2018

jklmli commented May 23, 2017 •

edited

Loading

acburdine commented May 24, 2017 •

edited

Loading

ghost commented May 26, 2017 •

edited by ghost

Loading

blimmer commented May 29, 2017 •

edited

Loading

selfagency commented Jun 23, 2017 •

edited

Loading