yo version check fails if proxy ENVs configured and npm registry is listed in NO_PROXY

[carlost]

Type of issue

Bug

My environment

• OS version/details: MacOS 10.13.4 (high sierra)
• Node version: v8.11.1
• npm version: 6.4.1
• Version of yo : 2.0.5

Expected behavior

I expected the yo version check to respect my ENV proxy settings as configured, similar to how most other tools treat them.

Current behavior

The use of the global-tunnel-ng module added in this commit forces the yo-version rule to use proxy as per global-tunnel-ng config rules (e.g. presence of ENV vars ).

Unfortunately global-tunnel-ng ignores the presence of NO_PROXY config.

So if you are in the unfortunate circumstance of:

1. Having npm config or env var proxy config, and
2. Use an npm registry that is in a private area in front of the proxy

Running yo doctor will spit out socket errors when it attempts to access the registry through the proxy.

Steps to reproduce the behavior

1. Configure npm to access a registry in front of a proxy,
2. export relevant proxy vars (http_proxy, https_proxy, no_proxy etc.) making sure that the npm registry is correctly listed in no_proxy,
3. run yo doctor

Command line output

$ yo doctor

Yeoman Doctor
Running sanity checks on your system

✔ Global configuration file is valid
✔ NODE_PATH matches the npm root
✔ Node.js version
✔ No .bowerrc file in home directory
✔ No .yo-rc.json file in home directory
✔ npm version
{ RequestError: tunneling socket could not be established, statusCode=503
    at ClientRequest.req.once.err (/usr/local/lib/node_modules/yo/node_modules/latest-version/node_modules/got/index.js:73:21)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at ClientRequest.onConnect (/usr/local/lib/node_modules/yo/node_modules/tunnel/lib/tunnel.js:157:23)
    at Object.onceWrapper (events.js:319:30)
    at emitThree (events.js:136:13)
    at ClientRequest.emit (events.js:217:7)
    at Socket.socketOnData (_http_client.js:472:11)
    at emitOne (events.js:116:13)
  code: 'ECONNRESET',
  message: 'tunneling socket could not be established, statusCode=503',
  host: 'THE-PRIVATE-REGISTRY.TLD',
  hostname: 'THE-PRIVATE-REGISTRY.TLD',
  method: 'GET',
  path: '/nexus/repository/our-npm-group/yo' }
✖ yo version
{ RequestError: tunneling socket could not be established, statusCode=503
    at ClientRequest.req.once.err (/usr/local/lib/node_modules/yo/node_modules/latest-version/node_modules/got/index.js:73:21)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at ClientRequest.onConnect (/usr/local/lib/node_modules/yo/node_modules/tunnel/lib/tunnel.js:157:23)
    at Object.onceWrapper (events.js:319:30)
    at emitThree (events.js:136:13)
    at ClientRequest.emit (events.js:217:7)
    at Socket.socketOnData (_http_client.js:472:11)
    at emitOne (events.js:116:13)
  code: 'ECONNRESET',
  message: 'tunneling socket could not be established, statusCode=503',
  host: 'THE-PRIVATE-REGISTRY.TLD',
  hostname: 'THE-PRIVATE-REGISTRY.TLD',
  method: 'GET',
  path: '/nexus/repository/our-npm-group/yo' }

Found potential issues on your machine :(
✖ yo version

Your yo version is outdated.

Upgrade to the latest version by running:
npm install -g yo@latest

Error: callback() can only be called once.
    at onetime (/usr/local/lib/node_modules/yo/node_modules/each-async/node_modules/onetime/index.js:15:11)
    at rule.verify.err (/usr/local/lib/node_modules/yo/node_modules/yeoman-doctor/lib/index.js:23:7)
    at binVersionCheck.then (/usr/local/lib/node_modules/yo/node_modules/yeoman-doctor/lib/rules/yo-version.js:21:23)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

I recognize that this really is a global-tunnel-ng issue but I want you to be aware of it as well.

[SBoudrias]

Could you open an issue on global-tunnel-ng about that problem:

Unfortunately global-tunnel-ng ignores the presence of NO_PROXY config.

Sounds like we'd just want a fix on that package.

[carlost]

@SBoudrias I added an issue in the global-tunnel-ng repo the same day i created this one. I added the issue here mainly to alert yeoman users about this without having to dig into the source.

[JoshuaKGoldberg]

Seems that this is still blocked on np-maintain/global-tunnel#38. FYI @UlisesGascon, I added a status: blocked label just now and applied it to this repo.