"Command not found" output on Windows

[harriha]

Hi,

After the yarn support was added, the output is surely much nicer in many ways, thumbs up for that 👍. However, especially if comparing reality to the README example of the case when yarn is not installed, the output could optimally be cleaner. I believe this is more relevant than before as everyone is not using yarn.

On Git Bash on Windows 10:

$ ./node_modules/.bin/check-node-version
node: 6.10.1
npm: 3.10.10
'yarn' is not recognized as an internal or external command,
operable program or batch file.

On CentOS 7:

$ ./node_modules/.bin/check-node-version
node: 6.10.1
npm: 3.10.10
/bin/sh: yarn: command not found

Would be nice to have the yarn: not installed as the output, although surely the current output delivers the essential message.

[parshap]

Thanks for the report! Fixed the output to match the readme in check-node-version@2.1.0.

[harriha]

Hi,

Thanks! Seems to be fine on two Linux distros I tested (Ubuntu, CentOS), but the usual troublemaker called Windows is still as it was before.

Based on brief testing, things make sense when executing the command in shell directly, but the real exit code doesn't come through from child_process.exec, the code is always 1:

# Windows cmd prompt
C:\repos\tmp\cnv>yarn --version
'yarn' is not recognized as an internal or external command,
operable program or batch file.

C:\repos\tmp\cnv>echo %errorlevel%
9009

# Git bash
MINGW64 ~/repos/tmp/cnv
$ yarn --version
bash: yarn: command not found

MINGW64 ~/repos/tmp/cnv
$ echo $?
127

# check-node-version
$ ./node_modules/.bin/check-node-version
node: 6.10.1
npm: 3.10.10
'yarn' is not recognized as an internal or external command,
operable program or batch file.

I'm not very experienced with this kind of hacking, but perhaps one could get forward with a Windows-specific wrapper using tips such as this, but not sure if worth the trouble, as things are likely to get awkward and this is a fairly minor issue anyway (IMO).

[parshap]

Hmm, interesting. So the value for execError.code here is 1? I wonder if there are any other properties on the error object that will allow us to identify it. I will reopen this issue, but I won't be able to investigate the problem further. If you come across a fix, please send a PR. :)

[harriha]

Yep, the error code returned from exec is always 1, the original one gets lots somewhere. I didn't see anything particularly useful in the error object, the only idea I had would be to regex the error message but that would be quite...suboptimal.

I would be happy to send a PR if there was just an idea for a reasonable fix, but I'm sensing that the complexity involved for properly handling this might not be justifiable. A quick fix might be to do the detection based on the error message, even though it would be far from a perfect solution.

[BurtHarris]

I'm running into the same error on Windows (my platform of habit.) Too bad Yarn is involved, I don't even know what that's about.

For now I guess I can take a dependency on check-node-version@^1. Does that make sense?

Do you want some help with this? I offer because, this error aside, check-node-version looks like "just what the doctor ordered". See https://stackoverflow.com/questions/44037774/requiring-npm-version-4-when-building-a-package-json for context.

P.S. Adding https://www.appveyor.com/ CI support might be a good way for this project to cross check itself against Windows.

[BurtHarris]

I looked into yarn, is it supposed to be an npm replacement? Do I need to consider scenarios where yarn is installed, but npm is not?

[harriha]

BurtHarris, when checking your use case from the SO question, I can see how this might be quite an annoying thing for users of your library, easy to get confused by this error message about yarn.

Fixing this error message would be one thing, but your case and message got me thinking that wouldn't it make more sense, if, when checking against specific components, the list output of installed components would include only those instead of all of them? Especially now when both yarn and npm exist and probably only one of them is interesting in most cases, this would keep the output more relevant. Without any arguments the listing could include all components as before. @parshap, any thoughts?

[bastienmoulia]

Can't we just not call the yarn command when yarn is not specified in option or in the "engines"?

[parshap]

when checking against specific components, the list output of installed components would include only those instead of all of them

Can't we just not call the yarn command when yarn is not specified in option or in the "engines"?

Yes, this sounds reasonable to me.

Do you want some help with this?

Yes, please! I would greatly appreciate a PR for this change or to add a appveyor.yml. Otherwise, I'll try to get to it asap.