jestjs / jest

Delightful JavaScript Testing.
https://jestjs.io
MIT License
44.32k stars 6.47k forks source link

Yarn hangs when installing jest@22.0.x #5169

Closed alexilyaev closed 6 years ago

alexilyaev commented 6 years ago

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

What is the current behavior? Yarn hangs on yarn add -D jest@22.0.4.
Works fine with v21.2.1.
I deleted node_modules and yarn.lock and ran yarn cache clean just to make sure.

If the current behavior is a bug, please provide the steps to reproduce and either a repl.it demo through https://repl.it/languages/jest or a minimal repository on GitHub that we can yarn install and yarn test.

$ yarn add -D jest@22.0.0
yarn add v1.3.2
[1/4] πŸ”  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] πŸ”—  Linking dependencies...
[4/4] πŸ“ƒ  Building fresh packages...
⠁
⠁
⠁
[1/1] β‘€ weak
[-/1] β‘€ waiting...
[1/1] ⠁ weak
[1/1] β‘€ weak
[1/1] ⠈ weak
[1/1] ⠁ weak
[-/1] ⠁ waiting...
[-/1] ⠁ waiting...
[-/1] ⠁ waiting...
[-/4] β „ waiting...
[-/4] β „ waiting...
[3/4] β „ weak
[-/4] β „ waiting...
[-/4] β „ waiting...

With --verbose:

...
verbose 16.456 Removing extraneous file "/Users/alex/.config/yarn/global/node_modules/tabtab/node_modules/.bin".
verbose 16.456 Removing extraneous file "/Users/alex/.config/yarn/global/node_modules/tar-pack/node_modules/.bin".
verbose 16.457 Removing extraneous file "/Users/alex/.config/yarn/global/node_modules/yarn-completions/node_modules".
verbose 16.457 Removing extraneous file "/Users/alex/.config/yarn/global/node_modules/yarn/node_modules/.bin".
verbose 16.458 Removing extraneous file "/Users/alex/.config/yarn/global/node_modules/yarn-completions/node_modules/.bin".
[-/5] β „ waiting...
[-/5] β „ waiting...
[-/5] β‘€ waiting...
[-/5] β‘€ waiting...
[-/5] β‘€ waiting...
[4/5] β‘€ weak
[4/4] πŸ“ƒ  Building fresh packages...
[1/4] β „ spawn-sync
[-/5] ⠁ waiting...
[-/5] ⠁ waiting...
[3/4] β   weak
[-/4] β   waiting...
verbose 17.204 Sun, 24 Dec 2017 14:31:40 GMT tabtab:installer Installing completion script to bashrc directory
Sun, 24 Dec 2017 14:31:40 GMT tabtab:installer Installing completion script to /Users/alex/.bashrc directory
[-/5] β‘€ waiting...
[-/5] β‘€ waiting...
[3/4] ⠁ weak
[-/4] ⠁ waiting...
verbose 18.416 node-pre-gyp info it worked if it ends with ok
node-pre-gyp info using node-pre-gyp@0.6.39
node-pre-gyp info using node@9.3.0 | darwin | x64
node-pre-gyp info check checked for "/Users/alex/.config/yarn/global/node_modules/fsevents/lib/binding/Release/node-v59-darwin-x64/fse.node" (not found)
node-pre-gyp http GET https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.1.3/fse-v1.1.3-node-v59-darwin-x64.tar.gz
node-pre-gyp http 200 https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.1.3/fse-v1.1.3-node-v59-darwin-x64.tar.gz
node-pre-gyp info install unpacking fse.node
[-/5] β „ waiting...
[-/4] ⠈ waiting...
[3/4] ⠈ weak
[-/4] ⠈ waiting...
[-/4] ⠈ waiting...

What is the expected behavior? Should not hang

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.

Node v9.3.0 Yarn 1.3.2 Mac OS X 10.12.6

SimenB commented 6 years ago

@mjesun Ideas?

guywaldman commented 6 years ago

Experienced this issue as well.

Node v9.3.0 Yarn 1.3.2 MacOS High Sierra 10.13.1

jnrepo commented 6 years ago

npm i w/ jest 22.0.4 throw this error log and fails

> weak@1.0.1 install /Users/me/project/node_modules/weak
> node-gyp rebuild

  CXX(target) Release/obj.target/weakref/src/weakref.o
clang: warning: using sysroot for 'iPhoneSimulator' but targeting 'MacOSX' [-Wincompatible-sysroot]
  SOLINK_MODULE(target) Release/weakref.node
clang: warning: using sysroot for 'iPhoneSimulator' but targeting 'MacOSX' [-Wincompatible-sysroot]
ld: building for OSX, but linking against dylib built for iOS (/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.2.sdk/usr/lib/libc++.tbd). file '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.2.sdk/usr/lib/libc++.tbd' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Release/weakref.node] Error 1
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:258:23)
gyp ERR! stack     at emitTwo (events.js:125:13)
gyp ERR! stack     at ChildProcess.emit (events.js:213:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Darwin 17.3.0
gyp ERR! command "/usr/local/Cellar/node/8.2.1/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/me/project/node_modules/weak
gyp ERR! node -v v8.2.1
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok 
npm WARN react-native@0.51.0 requires a peer of react@16.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN react-native-calendar-picker@5.9.0 requires a peer of babel-preset-expo@^2.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN react-native-maps@0.19.0 requires a peer of react@16.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: weak@1.0.1 (node_modules/weak):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: weak@1.0.1 install: `node-gyp rebuild`
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1
SamPruden commented 6 years ago

Can confirm, I've got another similar case of this with NPM on Windows here. I think I've partially tracked down the issue.

[MY DEV DIRECTORY]\[MY PACKAGE]\node_modules\weak>if not defined npm_config_node_gyp (node "C:\Users\A\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\Users\A\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
  weakref.cc
  win_delay_load_hook.cc
..\src\weakref.cc(17): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory [[MY DEV DIRECTORY]\[MY PACKAGE]\node_modules\weak\build\weakref.vcxproj]
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h(31): fatal error C1083: Cannot open include file: 'ctype.h': No such file or directory (compiling source file C:\Users\A\AppData\Roaming\npm\node_modu
les\npm\node_modules\node-gyp\src\win_delay_load_hook.cc) [[MY DEV DIRECTORY]\[MY PACKAGE]\node_modules\weak\build\weakref.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Users\A\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\lib\build.js:258:23)
gyp ERR! stack     at ChildProcess.emit (events.js:159:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:12)
gyp ERR! System Windows_NT 10.0.10586
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\A\\AppData\\Roaming\\npm\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd [MY DEV DIRECTORY]\[MY PACKAGE]\node_modules\weak
gyp ERR! node -v v9.3.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok

The internal jest-leak-detector module introduces a dependency on weak, which seems to have some problems installing on Windows. @jaylandro seems to have independently tracked this down and filed an issue over there. I've tried to manually npm i weak with the same results, so the problem isn't anywhere in jest itself.

The issue may partly be related to my dev environment, as reports seem a little inconsistent on this. I have the windows-build-tools package and gyp stuff usually works fine, but I don't have much experience messing with gyp stuff. Whether the issue is partly dependent on our environments or not, I think this should be considered a bug as it introduces some new undocumented dependency with no clear fix.

Glancing through the issues on the weak repo it looks like it's not particularly actively maintained and has a few outstanding problems, perhaps if jest is going to take a dependency on this it might make sense for the team to take a fork or something.

I'd appreciate if this dependency could be rolled-back for now until this is sorted, as I just went through the whole process of

Huh that's strange. Oh, Jest can't handle module.parent, I should file a request. Oh, someone just did, and it just got added to the latest version, sweet. npm i --save-dev jest@22. Oh. Damn.

EDIT: I should note that I'm running Windows 10, node v9.3.0, npm v5.6.0, node-gyp v3.6.2, windows-build-tools v1.3.2 and running the npm i from an admin prompt. I haven't tracked down specifically why it's giving the file-not-found error that it is.

SimenB commented 6 years ago

This is really weird, as weak is an optionalDependency. If installing it fails, it should just be ignored... See #4984.

SamPruden commented 6 years ago

@SimenB The copy of jest-leak-detector I'm getting from npm for the jest install has these dependencies, it's listed as both.

  "dependencies": {
    "pretty-format": "^22.0.3",
    "weak": "^1.0.1"
  },
...
  "optionalDependencies": {
    "weak": "^1.0.1"
  },

I'm not too sure what's going on with that package.json though, the version in the repo is significantly shorter than the version that comes down from npm and doesn't contain the duplicate. Is there a build-step doing something to it somewhere?

My full copy of jest-leak-detector/package.json:

{
  "_from": "jest-leak-detector@^22.0.3",
  "_id": "jest-leak-detector@22.0.3",
  "_inBundle": false,
  "_integrity": "sha512-xyVdAmcG8M3jWtVeadDUU6MAHLBrjkP4clz2UtTZ1gpe5bRLk27VjQOpzTwK20MkV/6iZQhSuRVuzHS5kD0HpA==",
  "_location": "/jest-leak-detector",
  "_phantomChildren": {
    "ansi-styles": "3.2.0"
  },
  "_requested": {
    "type": "range",
    "registry": true,
    "raw": "jest-leak-detector@^22.0.3",
    "name": "jest-leak-detector",
    "escapedName": "jest-leak-detector",
    "rawSpec": "^22.0.3",
    "saveSpec": null,
    "fetchSpec": "^22.0.3"
  },
  "_requiredBy": [
    "/jest-runner"
  ],
  "_resolved": "https://registry.npmjs.org/jest-leak-detector/-/jest-leak-detector-22.0.3.tgz",
  "_shasum": "b64904f0e8954a11edb79b0809ff4717fa762d99",
  "_spec": "jest-leak-detector@^22.0.3",
  "_where": "C:\\Users\\A\\Dev\\eq-engine\\node_modules\\jest-runner",
  "bugs": {
    "url": "https://github.com/facebook/jest/issues"
  },
  "bundleDependencies": false,
  "dependencies": {
    "pretty-format": "^22.0.3",
    "weak": "^1.0.1"
  },
  "deprecated": false,
  "description": "Module for verifying whether an object has been garbage collected or not.",
  "homepage": "https://github.com/facebook/jest#readme",
  "license": "MIT",
  "main": "build/index.js",
  "name": "jest-leak-detector",
  "optionalDependencies": {
    "weak": "^1.0.1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/facebook/jest.git"
  },
  "version": "22.0.3"
}
SimenB commented 6 years ago

Oh, that's really interesting! You just found a bug in either lerna or yarn.

$ y info jest-leak-detector dependencies
yarn info v1.3.2
{ 'pretty-format': '^22.0.3',
  weak: '^1.0.1' }
✨  Done in 0.20s.
SamPruden commented 6 years ago

Well that's fun. I've actually never directly touched either of those packages so I can't particularly comment on the details of that. If there's no easy fix for this on your end until that gets patched in lerna/yarn, is it feasible to manually patch the package.json that's going to npm to fix this until that gets sorted?

I'd offer to PR it, but it's probably best I don't mess with a buggy build process that I don't really understand.

SimenB commented 6 years ago

Seems like it's by design... https://github.com/npm/npm/issues/3502

But "If there's a dep in dependencies, but it's also in optionalDependencies, then the optional-ness takes precedence.", so it should still work (just really confusing). I don't understand why it fails your build, then.

If you have a package.json like this:

{
  "name": "some-name",
  "version": "0.0.0",
  "optionalDependencies": {
    "weak": "^1.0.1"
  }
}

and run npm install, does it exit successfully?

SamPruden commented 6 years ago

We were actually thinking along the same lines so I was just about to try that. And that gives the same errors but then skips it when it fails.

C:\Users\A\Dev\temp\node-weak-issue-recreation>npm i

> weak@1.0.1 install C:\Users\A\Dev\temp\node-weak-issue-recreation\node_modules\weak
> node-gyp rebuild

C:\Users\A\Dev\temp\node-weak-issue-recreation\node_modules\weak>if not defined npm_config_node_gyp (node "C:\Users\A\AppData\Roaming\npm\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\Users\A\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
  weakref.cc
  win_delay_load_hook.cc
..\src\weakref.cc(17): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory [C:\Users\A\Dev\temp\node-weak-issue-recrea
tion\node_modules\weak\build\weakref.vcxproj]
C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h(31): fatal error C1083: Cannot open include file: 'ctype.h': No such file or directory (co
mpiling source file C:\Users\A\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\src\win_delay_load_hook.cc) [C:\Users\A\Dev\temp\node-weak-
issue-recreation\node_modules\weak\build\weakref.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Users\A\AppData\Roaming\npm\node_modules\npm\node_modules\node-gyp\lib\build.js:258:23)
gyp ERR! stack     at ChildProcess.emit (events.js:159:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:12)
gyp ERR! System Windows_NT 10.0.10586
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\A\\AppData\\Roaming\\npm\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Users\A\Dev\temp\node-weak-issue-recreation\node_modules\weak
gyp ERR! node -v v9.3.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN some-name@0.0.0 No description
npm WARN some-name@0.0.0 No repository field.
npm WARN some-name@0.0.0 No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: weak@1.0.1 (node_modules\weak):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: weak@1.0.1 install: `node-gyp rebuild`
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1

up to date in 4.855s
SamPruden commented 6 years ago

And weirdly, I get the same with this, too...

{
  "name": "some-name",
  "version": "0.0.0",
  "dependencies": {
    "weak": "^1.0.1"
  },
  "optionalDependencies": {
    "weak": "^1.0.1"
  }
}
SimenB commented 6 years ago

and echo $? is 0?

What about npm install jest-leak-detector?

SamPruden commented 6 years ago

So, after running npm i on that test package, the directory now looks like this...

Unless you know what's going on there, that looks like I might have some deeper issue here, I'll try reinstalling npm and see if that fixes anything. The existence of this issue, not opened by me, seems to be testament to the fact that there's some deeper issue here though...

image

SamPruden commented 6 years ago

echo $? is a unix thing and I'm on Windows, but the equivalent echo %errorlevel% is 0, yes.

npm install jest-leak-detector behaves the same as that demo recreation, shows the error but exits successfully. That seems to work correctly, I'm now unable to recreate the weird files issue, running the test package you suggested now correctly skips the dependency when it fails. This is all really weird.

SamPruden commented 6 years ago

So, after seeing those work, I just tried to npm i --save-dev jest@22 again and it worked... I'm now running jest v22.0.4 successfully, and the tests that rely on module.parent are working, yay.

I never did get around to reinstalling anything, it just suddenly worked...

I'm not sure what to make of this now, or whether to consider this a just-me issue that somehow fixed itself, or a jest issue. There do seem to be a few people having issues here though, which suggests it's something wider.

My current hunch is that it's something funky in the weak package that caused the problems I had here, which would still make it a problem for jest.

SamPruden commented 6 years ago

Just to note, I incorrectly said node-weak as the package name a few times here, it's actually just weak, the repo is called node-weak. I've edited that in my comments, but I can confirm that I wasn't accidentally installing the node-weak package instead at any point, that doesn't even exist.

SamPruden commented 6 years ago

To summarise:

Furthermore, there seem to be a number of open issues at TooTallNate/node-weak related to various install issues and crashes that have received no response for a number of months, indicating it may have stability issues. See https://github.com/TooTallNate/node-weak/issues/81, https://github.com/TooTallNate/node-weak/issues/74, https://github.com/TooTallNate/node-weak/issues/73

Even if this is working as intended by skipping, jest probably doesn't want the scary red gyp ERR ... block in the install process on most systems, even if npm does tell you not to worry at the end.

I'd suggest that it looks like weak may not be a package that jest wants to deal with for now, it seems it may prove a general maintenance liability.

EDIT: I'd already tried clearing npm caches and making sure npm was up to date before I ever posted in this thread.

brittbinler commented 6 years ago

I'm experiencing this problem too.

Node 8.9.1 Yarn 1.3.2 NPM 5.5.1 Mac OS X 10.12.6

jaylandro commented 6 years ago

This is concerning that the codebase does not match the published npm package for jest-leak-detector. In github the package.json clearly has weak as an optional dependency: https://github.com/facebook/jest/blob/v22.0.4/packages/jest-leak-detector/package.json

Yet in the package.json published in npm, it is a dependency.

  "dependencies": {
    "pretty-format": "^22.0.3",
    "weak": "^1.0.1"
  },

I originally came across this issue using npm version 3.10.10 and node verison 6.11.3 inside of a nanoserver docker container, so python dependencies for a weak node-gyp rebuild are a no go.

SimenB commented 6 years ago

It's supposed to be in dependencies as well (https://github.com/npm/npm/issues/3502). This seems like an implementation detail leaking out, but nothing to worry about.

But if the package managers with 1 then it's an issue. I'm not sure if it's jest's fault, or something we can fix, though

jaylandro commented 6 years ago

Okay, if that is the case, we should make sure that the pre-compiled binaries are published by weak's build pipeline. https://travis-ci.org/TooTallNate/node-weak/builds/100044569

I believe for that to happen there would need to be an AppVeyor build pipeline in addition to the Travis CI build pipeline to compile the Windows binaries.

SamPruden commented 6 years ago

@brittbinler Could you post an error-log or something? What exactly are you experiencing? There seem to be a few semi-related problems mixed into one here. It's interesting that you're seeing something like this on OSX, there goes my theory that it might be a Windows specific issue.

mjesun commented 6 years ago

It seems then that the bug is Yarn specific, since NPM is able to skip the dependency when the binary module is not built (that's based on what people posted earlier). Generally speaking, weak is an optional dependency for that common reason where the machines used for testing do not have an internet connection nor node-gyp installed.

cc / @BYK or @arcanis could we double-check that Yarn's behavior is the right one? Thanks!

jaylandro commented 6 years ago

@mjesun This is not yarn specific, I ran into this using standard npm install. This is an issue with utilizing native node modules like weak which if there is not a binary that matches your OS and node version it attempts to compile the C++ as part of the install process. If you do not have python 2.7 in your path, node-gyp will error out. I suspect the Mac user experiencing this has python 3 in their path, which is not compatible.

mjesun commented 6 years ago

@jaylandro Oh sorry, I just realized that people with npm is also experiencing a non-zero exit code. Being listed as optional, the compile phase should crash and the install should continue normally, skipping the dependency. I'm not sure what's going on 😞

SamPruden commented 6 years ago

@mjesun To be clear, since I first reported an issue mine now exits with error code zero, but I don't know what fixed it.

As a slight aside, I'm personally not a fan of a popular library like jest having an install experience that looks scary even when it works, I don't know if that's something you guys care about or not. My working install looks like this. image If I saw this and didn't know what was going on, I'd be concerned and spend some time investigating despite the eventual skipping of the failure.

mjesun commented 6 years ago

Yeah, I think we might remove the dependency to jest-leak-detector (either converting it to peer, or removing it completely), and hard crashing whenever leak detection needs to be used but jest-leak-detector is not on your node_modules folder.

alexilyaev commented 6 years ago

@jaylandro Trying to keep up with the busy discussion :-)

$ python --version
Python 2.7.10
brittbinler commented 6 years ago

@SamPruden Sure thing - here's console output while trying to install with yarn:

$ yarn
yarn install v1.3.2
[1/4] πŸ”  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] πŸ”—  Linking dependencies...
[4/4] πŸ“ƒ  Building fresh packages...
[1/4] β „ uglifyjs-webpack-plugin
[2/4] β „ fsevents
[-/4] β‘€ waiting...
[-/4] β‘€ waiting...
[-/4] β‘€ waiting...
[-/4] β‘€ waiting...
[-/4] β‘€ waiting...
[-/4] β‘€ waiting...
[-/4] β‘€ waiting...
[-/4] β‘€ waiting...
[4/4] β‘€ weak
[4/4] πŸ“ƒ  Building fresh packages...
[-/2] ⠁ waiting...
[2/2] ⠁ weak
[-/2] ⠁ waiting...
[-/2] ⠁ waiting...
[-/2] ⠁ waiting...

Here's console output when installing with npm:

$ npm install

> fsevents@1.1.3 install [Project directory]/node_modules/fsevents
> node install

[fsevents] Success: "[Project directory]/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

> weak@1.0.1 install [Project directory]/node_modules/weak
> node-gyp rebuild

  CXX(target) Release/obj.target/weakref/src/weakref.o
  SOLINK_MODULE(target) Release/weakref.node

> node-sass@4.7.2 install [Project directory]/node_modules/node-sass
> node scripts/install.js

Cached binary found at [User directory]/.npm/node-sass/4.7.2/darwin-x64-57_binding.node

> uglifyjs-webpack-plugin@0.4.6 postinstall [Project directory]/node_modules/webpack/node_modules/uglifyjs-webpack-plugin
> node lib/post_install.js

> node-sass@4.7.2 postinstall [Project directory]/node_modules/node-sass
> node scripts/build.js

Binary found at [Project directory]/node_modules/node-sass/vendor/darwin-x64-57/binding.node
Testing binary
Binary is fine
added 1572 packages in 41.099s

Here's my package.json file:

{
  "name": "project",
  "private": true,
  "dependencies": {
    "autoprefixer": "^7.1.6",
    "babel-core": "^6.26.0",
    "babel-plugin-syntax-dynamic-import": "^6.18.0",
    "babel-plugin-transform-class-properties": "^6.24.1",
    "babel-plugin-transform-decorators-legacy": "1.3.4",
    "babel-polyfill": "^6.26.0",
    "babel-preset-env": "^1.6.1",
    "babel-preset-react": "^6.24.1",
    "babel-preset-stage-1": "^6.24.1",
    "babel-preset-stage-2": "^6.24.1",
    "babelify": "^8.0.0",
    "bootstrap": "^3.3.7",
    "browserify": "^14.5.0",
    "coffee-loader": "^0.9.0",
    "coffeescript": "^2.1.0",
    "compression-webpack-plugin": "^1.0.1",
    "cropperjs": "^1.1.3",
    "cross-fetch": "^1.1.1",
    "css-loader": "^0.28.7",
    "dotenv": "^4.0.0",
    "extract-text-webpack-plugin": "^3.0.2",
    "file-loader": "^1.1.5",
    "glob": "^7.1.2",
    "ip": "^1.1.5",
    "jquery": "^3.2.1",
    "js-yaml": "^3.10.0",
    "marked": "^0.3.6",
    "moment": "^2.19.3",
    "node-sass": "^4.7.2",
    "path-complete-extname": "^0.1.0",
    "postcss-loader": "^2.0.8",
    "postcss-smart-import": "^0.7.5",
    "precss": "^2.0.0",
    "prop-types": "^15.6.0",
    "pusher-js": "^4.2.1",
    "rails-erb-loader": "^5.2.1",
    "react": "^16.1.1",
    "react-dnd": "^2.5.4",
    "react-dnd-html5-backend": "^2.5.4",
    "react-dom": "^16.1.1",
    "react-redux": "^5.0.6",
    "redux": "^3.7.2",
    "redux-logger": "^3.0.6",
    "redux-thunk": "^2.2.0",
    "resolve-url-loader": "^2.2.0",
    "sass-loader": "^6.0.6",
    "style-loader": "^0.19.0",
    "swiper": "3.4.2",
    "underscore": "^1.8.3",
    "uppy": "^0.21.0",
    "webpack": "^3.8.1",
    "webpack-manifest-plugin": "^1.3.2",
    "webpack-merge": "^4.1.1"
  },
  "devDependencies": {
    "babel-loader": "^7.1.2",
    "browserify-incremental": "^3.1.1",
    "identity-obj-proxy": "^3.0.0",
    "jest": "^22.0.4",
    "jest-cli": "^22.0.4",
    "jquery-mockjax": "^2.2.2",
    "react-test-renderer": "^16.2.0",
    "redux-mock-store": "^1.4.0",
    "uglifyjs-webpack-plugin": "^1.1.1",
    "webpack-dev-server": "^2.9.4"
  },
  "scripts": {
    "test": "jest",
    "test:watch": "npm test -- --watch"
  },
  "jest": {
    "testPathIgnorePatterns": [
      "/node_modules/",
      "/config/",
      "/vendor/"
    ],
    "moduleNameMapper": {
      "^.+\\.(css|less|scss)$": "identity-obj-proxy"
    }
  }
}
andreimcristof commented 6 years ago

Got the exact same issue right now. It hangs here:

[3/4] β   node-sass: Downloading binary from https://github.com/sass/node-sass/releases/download/v4.7.2/darwin-x64-59_binding.node [-/4] β’€ waiting... [-/4] β   waiting... [3/4] β   node-sass: Downloading binary from https://github.com/sass/node-sass/releases/download/v4.7.2/darwin-x64-59_binding.node [4/4] β   uws [4/4] πŸ“ƒ Building fresh packages... [-/2] ⠐ waiting... [2/2] ⠐ weak [-/2] ⠐ waiting... [-/2] ⠐ waiting... [-/2] ⠐ waiting...

ng --version says:

Angular CLI: 1.6.3 Node: 9.3.0 OS: darwin x64 Angular: 5.1.2 ... animations, common, compiler, compiler-cli, core, forms ... http, platform-browser, platform-browser-dynamic ... platform-server, router

@angular/cdk: 5.0.3 @angular/cli: 1.6.3 @angular/material: 5.0.3 @angular-devkit/build-optimizer: 0.0.36 @angular-devkit/core: 0.0.22 @angular-devkit/schematics: 0.0.42 @ngtools/json-schema: 1.1.0 @ngtools/webpack: 1.9.3 @schematics/angular: 0.1.11 @schematics/schematics: 0.0.11 typescript: 2.6.2 webpack: 3.10.0

python --version says:

[20:46] frontend: python --version Python 2.7.10

npm --version says:

[20:48] frontend: npm --version 5.6.0

Thank you in advance for any input.

chigix commented 6 years ago

I've also met this problem when installing jest 22+ and I am developing on Windows 10 where I have no python environment:

2018-01-05_23-04-18

Although there is no problem in code testing and running the jest command, is executable python environment really needed for package, on design?

alexilyaev commented 6 years ago

Works fine with v22.0.5, can close the ticket if someone else confirms.

SimenB commented 6 years ago

5252

jukben commented 6 years ago

I had the same problem on MacOS. Be sure that you don't have any pending System Update. I've upgraded to macOS 10.13.3 (from the previous minor version) and the problem is gone.

macOS: 10.13.3 node: v9.3.0 yarn: 1.3.2

github-actions[bot] commented 3 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.