Incorrectly waits for stdin

[Igloczek]

Looks like ncu is currently not compatible with Node v4.1.0. I can run ncu, but nothing happens - cursor just goes to new line.

[raineorshine]

I installed node v4.1.0 and ran ncu without a problem. All unit tests passing, too.

What happens when you run this command?

echo '{"dependencies":{"express": "1"}}' | ncu

Please provide any additional information you can about the problem.

[Igloczek]

echo '{"dependencies":{"express": "1"}}' | ncu
express  1  →  4 

ncu without any extra parameters works too, but it takes over 3 minutes to get results...

[raineorshine]

It looks like it's working. It may take a long time if your package.json is long since npm view has to be called for each dependency to get the latest version number. If you know of a way to get latest versions of multiple dependencies in one call, we could speed this up considerably, but npm view does not appear to support it.

A user experience improvement would be to buffer the results to stdout so that you could see dependencies as they were found, instead of waiting till the end. This would require a significant refactor.

Sorry I don't have a good answer. Let me know if you think of something that I haven't!

[mrhyde]

I had pretty much the same issue last night, but it was apparently related to slow connection to npm registry. But as you said - it's not really intuitive at the moment and people can just stare there at blinking cursor and wondering that's going on. Is there any options for verbose output?

[raineorshine]

It would be simple enough to print “Finding latest versions from npm…” at
the start.

On Tue, Sep 22, 2015 at 5:46 PM Mr. Hyde notifications@github.com wrote:

I had pretty much the same issue last night, but it was apparently related
to slow connection to npm registry. But as you said - it's not really
intuitive at the moment and people can just stare there at blinking cursor
and wondering that's going on. Is there any options for verbose output?

—
Reply to this email directly or view it on GitHub
#136 (comment)
.

[mrhyde]

Sounds good for me :)

[kalmanb]

Note I had the same issue, was burning lot so CPU and not returning. Cleaned/removed node_modules directory fixed for me.

[raineorshine]

@kalmanb Thanks... I'm not sure what is happening there, but definitely is problematic. Let's keep an eye on it, and if we can reproduce it with a given install state then we can debug.

[etiktin]

Refactoring so we can check each dependency and print it's state as we get it sounds good to me. It will also make it easier to support interactive mode (#95).
For this to work we will need to rethink how we display satisfied dependencies that are not on the latest (currently we display them in a different group after all the unsatisfied).

Mean while, we could use the progress module or something similar, that allows us to show a progress bar in the CLI. The 'total' will be the number of dependencies and as we retrieve the latest version for each one, we will increase it by one. For example:

Finding latest versions [============--------] 60% 13.7s

[raineorshine]

Good points. We spent a bit of timing discussing satisfied text, but it's probably worth changing in order to get incremental installs and interactive mode. Let's discuss in #95.

Progress bar would be good!

[Daniel15]

ncu without any extra parameters works too, but it takes over 3 minutes to get results...

Are you using npm v3? It had pretty bad performance problems until recently (see http://blog.npmjs.org/post/130359991775/npm-weekly-31-npm-3-speed-fixes-modules-demoed and https://github.com/npm/npm/releases/tag/v3.3.6) which could explain the slowness

[Igloczek]

@Daniel15 Nope, npm v2.14.4 + node v4.1.1.

[raineorshine]

I'm tagging this unable-to-reproduce as aside from the performance issues mentioned above, which could give the appearance of nothing happening , I am unable to reproduce a concrete bug.

[mriehema]

I'm using npm v2.14.4 and node v4.1.1 with Windows 7, 64bit and ncu is not working. It starts, but never quits. Without any logs I cant check why. Tried to use it with "time ncu", because it may take longer, but I aborted it after 2 hours waiting. My package.json just has 16 entries. Any idea?

[raineorshine]

Hi Michael, thanks for reporting. Clearly it is getting hung up somewhere. We should add verbose logs so that we could at least see where it is hanging. Until then, the best we could do is actually debug from the source code.

Does it hang on an empty package.json? echo "{}" > package.json && ncu
Does it hang for some of the dependencies but not others? You could test this by removing some dependencies from your package.json and running ncu, or removing all of them and then adding them back in one-by-one.

Adding console.log's or more robust logging is going to be the best approach to really find where in the code it hangs, but since I cannot reproduce you may be on your own for the time being. Perhaps someone else who can reproduce would be willing to debug.

[mriehema]

Does it hang on an empty package.json? echo "{}" > package.json && ncu

Yes.

I tried to debug and added some logging to function programRunLocal() before return:

    console.log(pkgFileName);
    console.log(pkgFile);
    console.log(pkgData);

Tested with an empty package.json returns:

    package.json
    undefined
    lib$rsvp$promise$$Promise {
    _id: 0,
    _label: undefined,
    _state: undefined,
    _result: undefined,
    _subscribers: [] }

And it never gets to analyzeProjectDependencies() and doesn't stop.

[raineorshine]

Great information, thank you Michael. Maybe readFileAsync is not resolving? Can you tell if pkgData (promise) is resolving? Maybe add .catch to pkgData at the end of programRunLocal and see if an error is getting swallowed. Or try pkgData.then(console.log.bind(console, 'hi')) without the partial functional application, just to test a simpler case.

I wish I was able to reproduce and troubleshoot directly...

[raineorshine]

@mriehema I added verbose logging to v2.40. Can you upgrade then report the output of the following command?

ncu --loglevel verbose

[mriehema]

Awesome! I would upgrade and test it, if I could. :(

$ npm install npm-check-updates -g

> snyk@1.1.1 postinstall C:\Users\mriehema\AppData\Roaming\npm\node_modules\npm-check-updates\node_modules\snyk
> node cli/index.js help api-license

The use of Snyk's API, whether through the use of the 'snyk' npm package or otherwise, is subject to the terms & conditions specified here: https://snyk.io/policies/customer-agreement.pdf

C:\Users\mriehema\AppData\Roaming\npm\npm-check-updates -> C:\Users\mriehema\AppData\Roaming\npm\node_modules\npm-check-updates\bin\old-alias
C:\Users\mriehema\AppData\Roaming\npm\ncu -> C:\Users\mriehema\AppData\Roaming\npm\node_modules\npm-check-updates\bin\npm-check-updates

> npm-check-updates@2.4.0 postinstall C:\Users\mriehema\AppData\Roaming\npm\node_modules\npm-check-updates
> npm run snyk-protect


> npm-check-updates@2.4.0 snyk-protect C:\Users\mriehema\AppData\Roaming\npm\node_modules\npm-check-updates
> snyk protect

ENOENT: no such file or directory, open 'C:\Users\mriehema\AppData\Roaming\npm\node_modules\npm-check-updates\node_modules\bower\node_modules\handlebars\node_modules\uglify-js\.snyk-npm:uglify-js:20150824.flag'

npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\mriehema\\AppData\\Roaming\\npm\\node_modules\\npm-check-updates\\node_modules\\npm\\bin\\npm-cli.js" "run" "snyk-protect"
npm ERR! node v4.2.2
npm ERR! npm  v3.3.12
npm ERR! code ELIFECYCLE
npm ERR! npm-check-updates@2.4.0 snyk-protect: `snyk protect`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the npm-check-updates@2.4.0 snyk-protect script 'snyk protect'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the npm-check-updates package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     snyk protect
npm ERR! You can get their info via:
npm ERR!     npm owner ls npm-check-updates
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     C:\Users\mriehema\AppData\Roaming\npm\node_modules\npm-check-updates\npm-debug.log
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "npm-check-updates" "-g"
npm ERR! node v4.2.2
npm ERR! npm  v2.14.7
npm ERR! code ELIFECYCLE

npm ERR! npm-check-updates@2.4.0 postinstall: `npm run snyk-protect`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the npm-check-updates@2.4.0 postinstall script 'npm run snyk-protect'.
npm ERR! This is most likely a problem with the npm-check-updates package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     npm run snyk-protect
npm ERR! You can get their info via:
npm ERR!     npm owner ls npm-check-updates
npm ERR! There is likely additional logging output above.

[raineorshine]

Snyk would be great if it worked out of the box, but it's not worth adding if it is going to break in some environments. I'll remove it.

[raineorshine]

Try it now :). v2.4.1

[ghost]

@metaraine shouldn't synk be a dev-dep and not linked to install? npm install shouldn't do anything with synk

[mriehema]

@metaraine Thanks for your support. So I checked it:

$ ncu --loglevel verbose
Initializing...
Running in local mode...
Finding local package file...
Waiting for package data on stdin...

BTW: I updated to node v4.2.2 and npm v2.14.7

So it looks like it still hangs up like I described. I added following code:

    pkgData.then(function(value) {
      console.log(value); // "Success!"
      throw 'oh, no!';
    }).catch(function(e) {
      console.log(e); // "oh, no!"
    }).then(function(e){
      console.log('after a catch the chain is restored');
    }, function () {
      console.log('Not fired due to the catch');
    });

Well... Same output as before. Just no response of the Promise.

[mriehema]

Success! After some more debugging I tried to run it with explicit packageFile, and it works!

$ ncu --loglevel verbose --packageFile package.json
Initializing...
Running in local mode...
Finding local package file...
Getting installed packages...
Fetching latest versions...

All dependencies match the latest package versions :)

Looks like pkgData = require('get-stdin-promise'); is not working as expected.

[etiktin]

The question is why didn't it find the local package.json when you run it without parameters. "Finding local package file..." was supposed to succeed so it shouldn't have tried to read it from stdin.

By the way, we can replace get-stdin-promise with get-stdin since they added builtin support for promises in v5.0.0.

[kopax]

I have hit this issue on linux, when I have tried to invoke ncu using childProcess.spawn. Using --packageFile did the trick.

[angeldelacruzdev]

Hey guys, this command worked out for me.
Using gitbash MinTTY.
Try running this command
ncu -u --packageFile package.json

This Working

[KingDarBoja]

Any progress on this issue? Just curious... The provided workaround does work on Win 10 with Git Bash.

[raineorshine]

@KingDarBoja I don't believe anyone is actively working on this. Open to pull requests though.

[KingDarBoja]

@raineorshine Managed to solve the problem based on @kylios comment as I noticed the if-else check at findPackage function didn't took into account the pkgFileName value as it was set to default on getPackageFileName.

Something like this:

// ... More code
if (options.packageData) {
        pkgFile = null;
        pkgData = Promise.resolve(options.packageData);
    } else if (options.packageFile) {
        pkgFile = options.packageFile;
        pkgData = getPackageDataFromFile(pkgFile, pkgFileName);
    } else if (pkgFileName) { // extra check added :D 
        pkgFile = pkgFileName;
        pkgData = getPackageDataFromFile(pkgFile, pkgFileName);
    } else if (!process.stdin.isTTY) {
        // ... More code
    }
//... More code

Proof:

[raineorshine]

pkgFileName is always truthy, thus the code proposed would never reach if (!process.stdin.isTTY) { ... }, breaking stdin functionality. We need a solution that correctly detects isTTY across platforms.

[stoically]

Personally I think it might make sense to make reading from stdin opt-in, as breaking change. Since arguably reading from stdin is the much less used branch.

[raineorshine]

That makes sense to me.

[KingDarBoja]

@raineorshine I know but as most users have to provide the package filename by using the --packageFile option, it doesn't make sense to step into the process.stdin.isTTY part.

@stoically makes sense if someone wish to use it, as a new flag which should take priority over the existing checks and everyone would (I think) be happy about it.

[KingDarBoja]

No idea what changed on this library or my git bash but I no longer need --packageFile to make it work 🚀

[raineorshine]

@KingDarBoja Interesting. If an old version of ncu such as v2 works for you now, then it's your shell. Otherwise I'd be curious what exact version of ncu it started working for you.

[KingDarBoja]

@KingDarBoja Interesting. If an old version of ncu such as v2 works for you now, then it's your shell. Otherwise I'd be curious what exact version of ncu it started working for you.

I updated this week to 10.2.1 that's why I am surprised its working out of the box.

[raineorshine]

Well that's good news at least. It's unclear whether it's node, npm, ncu, or one of ncu's dependencies that fixed it. If someone else can confirm I'll close the issue!

[ncepuee]

I installed node v4.1.0 and ran ncu without a problem. All unit tests passing, too.

What happens when you run this command?

echo '{"dependencies":{"express": "1"}}' | ncu

Please provide any additional information you can about the problem.

hi，i meet with the problem:
my environment is：

NexT version 8.0.0
Documentation: https://theme-next.js.org
========================================
hexo: 5.3.0
hexo-cli: 4.2.0
os: Windows_NT 10.0.19041 win32 x64
node: 14.15.4
v8: 8.4.371.19-node.17
uv: 1.40.0
zlib: 1.2.11
brotli: 1.0.9
ares: 1.16.1
modules: 83
nghttp2: 1.41.0
napi: 7
llhttp: 2.1.3
openssl: 1.1.1i
cldr: 37.0
icu: 67.1
tz: 2020a
unicode: 13.0

and i use the code npm i -g npm-check-updates to install the package
it succeed，and then i use the git bash in my blog root directory，use ncu or ncu -u，it display this：

$ ncu -u
Hmmmmm... this is taking a long time. Your console is telling me to wait for input
on stdin, but maybe that is not what you want.
Try winpty ncu.cmd, or specify a package file explicitly with --packageFile package.json.
See https://github.com/raineorshine/npm-check-updates/issues/136#issuecomment-155721102

i see this issue，so which is the answer to this problem?

[raineorshine]

@hizablet Specify --packageFile package.json.

[donocode]

Just in case anyone ends up here while trying to run ncu through execa, you can make things work correctly with the stdin option:

execa('ncu', { preferLocal: true, stdin: process.stdin })

For some reason it does not work without it and only when piping stdout are you able to get a warning message which links here.

[raineorshine]

trying to run ncu through execa

(As an aside, you can require npm-check-updates which may work better in some circumstances if you're willing to have it as a local dependency.)

[tmarcinkowski-logitech]

For anyone using concurrently and experiencing this issue as well - you either need to explicitly set --packageFile as said before, or pass --raw option to concurrently (but you lose prefixing in this case).

An example:

npx concurrently \
  -n root,common,ui,api \
  "npx npm-check-updates --packageFile package.json" \
  "npx npm-check-updates --packageFile package.json --prefix common" \
  "npx npm-check-updates --packageFile package.json --prefix ui" \
  "npx npm-check-updates --packageFile package.json --prefix api"

[wangjing199196ok]

I installed node v4.1.0 and ran ncu without a problem. All unit tests passing, too.
What happens when you run this command?

echo '{"dependencies":{"express": "1"}}' | ncu

Please provide any additional information you can about the problem.

hi，i meet with the problem: my environment is：

NexT version 8.0.0
Documentation: https://theme-next.js.org
========================================
hexo: 5.3.0
hexo-cli: 4.2.0
os: Windows_NT 10.0.19041 win32 x64
node: 14.15.4
v8: 8.4.371.19-node.17
uv: 1.40.0
zlib: 1.2.11
brotli: 1.0.9
ares: 1.16.1
modules: 83
nghttp2: 1.41.0
napi: 7
llhttp: 2.1.3
openssl: 1.1.1i
cldr: 37.0
icu: 67.1
tz: 2020a
unicode: 13.0

and i use the code npm i -g npm-check-updates to install the package it succeed，and then i use the git bash in my blog root directory，use ncu or ncu -u，it display this：

$ ncu -u
Hmmmmm... this is taking a long time. Your console is telling me to wait for input
on stdin, but maybe that is not what you want.
Try winpty ncu.cmd, or specify a package file explicitly with --packageFile package.json.
See https://github.com/raineorshine/npm-check-updates/issues/136#issuecomment-155721102

i see this issue，so which is the answer to this problem?

Have you solved the problem yet? I have meet the same problem...

[raineorshine]

Auto stdin has been deprecated and will be removed in the next major version, which should fix the issue.

In the mean time, does using --packageFile package.json work for you?

[raineorshine]

Auto stdin removed in 7005bc6