Yarn: Yarn hangs at [1/4] Resolving packages or fails silently if --verbose

[ohir]

[email protected]
[email protected]
[email protected]
Linux newbox 4.4.153

A mrc test case: fresh install of webpack alone (after purging all caches etc.)

% rm -rf yarnfa
% mkdir yarnfa && cd yarnfa
cp ~/tmp/package.json.yarnfa ./package.json
% cat package.json
{
  "name": "yarnfa",
  "version": "0.1.0",
  "description": "yarn bug hang or silent",
  "main": "index.js",
  "repository": "",
  "author": "Ohir Ripe",
  "license": "none",
  "private": true,
  "devDependencies": {
    "webpack": "^4.23.0"
  }
}

cp ~/.yarnrc .
% cat .yarnrc
cache-folder /tgg/cache
yarn-offline-mirror /tgg/offline
yarn-offline-mirror-pruning true

# check if env is clean. It is.
% env | egrep -i 'nvm|npm|node'

yarn install

It is resolving some packages then it got stuck at number-is-nan@^1.0.0
Indicator spins but network download drops down to few hundred bps.
Without --verbose it then will hang (likely till lingering socket closes).
Repeated, it will hang on a few different packages from webpack deep deps.
Eg. ansi-regex, number-is-nan and a few others. None of them being huge.

If ran with --verbose yarn fails silently. Nothing is produced. The log last lines
are:

% yarn install --verbose > faillog && tail -n7 faillog

verbose 33.809 Performing "GET" request to "https://registry.yarnpkg.com/ansi-regex".
verbose 33.866 Request "https://registry.yarnpkg.com/minizlib" finished with status code 200.
verbose 33.868 Request "https://registry.yarnpkg.com/code-point-at" finished with status code 200.
verbose 33.885 Request "https://registry.yarnpkg.com/is-fullwidth-code-point" finished with status code 200.
verbose 33.886 Performing "GET" request to "https://registry.yarnpkg.com/number-is-nan".
verbose 33.976 Request "https://registry.yarnpkg.com/ansi-regex" finished with status code 200.
verbose 34.001 Request "https://registry.yarnpkg.com/number-is-nan" finished with status code 200.

The beginning of the log got .yarnrc four times:

yarn install v1.12.1
verbose 0.32 Found configuration file "/tgg/yarnfa/.yarnrc".
verbose 0.321 Found configuration file "/home/user/.yarnrc".
verbose 0.321 Found configuration file "/tgg/yarnfa/.yarnrc".
verbose 0.321 Found configuration file "/home/user/.yarnrc".
[1/4] Resolving packages...

NOTE paths redacted. No .npmrc present.
Yarn found project .yarnrc twice! And then twice homedir's one.
/tmp/yarnfa/.yarnrc is a copy of ~/.yarnrc
Current webpack version as of this filling is 4.23.1

NOTE possibly related to: #5055, #5491, #5512

[ddpardo]

I am also expiericing the mentioned behavoir.
Setup: Node 10.14.1 | Yarn 1.12.3 | npm 6.4.1 | Windows 10 (1803)

Using the following package.json

{
  "name": "test-yarn-resolving-package",
  "version": "1.0.0",
  "description": "test-yarn-resolving-package",
  "main": "index.js",
  "author": "-",
  "license": "MIT",
  "private": true,
  "dependencies": {
    "react": "^16.6.1",
    "react-dom": "^16.6.1"
  },
  "devDependencies": {}
}

Steps to reproduce:
Method one:

• yarn add webpack --dev (creates a yarn.lock and succeeds)
• yarn remove webpack
• yarn add webpack --dev (stuck on resolving phase or silently quits with --verbose passed)

Method two:

• yarn install (creates a yarn.lock)
• yarn add webpack --dev

[konpikwastaken]

+1

[ghost]

Hi, I am facing the same issue with [email protected]. It happens to me when using a private registry. The step 1 (resolving packages) works well but yarn exits with no logs when it starts fetching.

Regarding my network, I am using a whitelisting for fetching from my private registry.

@arcanis : any clues about what could be happening?

[gcaaa31928]

+1

[ghost]

Good news - in our case it seems to be more related to our network than anything else :D Sorry !

[ohir]

@jackTheRipper For the tooling it should not matter whether your network is fast or slow, whether it pass every packet or it drops 80% of. This heisenbug is awfull especially for people with poor connectivity - as tool does not timeout you must either watch net speedometer or set an ancient alarm clock beside your box then tinker manually with node or module's versions and you never know in what configurations yarn will progress. It gives that uneasy feeling that you can not trust in your basic tool.
If it gives up, it should say why it did so.

[ghost]

@ohir , I agree with you that the tool has to tell you what's up. But in our case, it's due to some weird settings in our proxy which creates a timeout while trying to retrieve the tarballs.

And that's why yarn dies silently I guess

[konpikwastaken]

Just some info in case anyone is looking into this - No proxy (http/https) here and network connection is stable but yarn fails with network connectivity issues. Downgrading to 1.9.4 seems more stable (and exits with the proper non-zero code) all subsequent versions bail with status code zero (which is a lie) and everything fails. Private registry.

[krzysztofgawrys]

launching with --network-concurrency 1 helps, yet whole "speed advantage" is out the window

[animamundi]

@profrook's solution worked for me, although it took ages!

[devmattrick]

I'm having the same issues as well, but also specifically on number-is-nan@^1.0.0, interestingly. Is there something about that specific package that's causing the issue?

[jousepo]

Same here with 1.13.0 / 1.14.0rc in Fedora 28 with a specific package with #develop.
In other computer with Ubuntu it works ok without problems....

EDIT: After a few retries it works but waiting a lot of time to resolve the dependency

[iranmarcius]

I'm having the same problem trying to use my private registry. The package is being transfered from it but it stuck at 'Resolving packages...'

My private registry is an apache http server with no authentication. the packages are in tgz format wich coontains package.json and the source files.

Yarn 1.17.3

[Jeff-Tian]

I met the same hang issues on [1/4] Resolving packages ...
It is super slow, that takes hours to complete.

By yarn --verbose that turns out the private registry connection is super slow.

Fixed by changing the .npmrc to public registry for those many public packages, and use slow registry only for scoped packages:

@company: registry = https://company-slow-registry.com
registry = https://registry.npmjs.org/