yo: 🐛 yo version check fails while behind proxy
Type of issue
🐛 bug
My environment
- OS version/details:
Windows 10 64-bit - Node version:
10.5.0 - npm version:
6.1.0 - Version of yo :
2.0.3
Expected behavior
I expect the version check to use the same proxy settings as npm does.
Current behavior
At work I’m sitting behind a company proxy and for some reason the version check fails while the install succeeds.
Command line output
PS C:\Users\xxqqvc\Projects\test> npm init -y
PS C:\Users\xxqqvc\Projects\test> ls
Directory: C:\Users\xxqqvc\Projects\test
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2018-07-04 11:48 200 package.json
PS C:\Users\xxqqvc\Projects\test> npm i --save yo
> spawn-sync@1.0.15 postinstall C:\Users\xxqqvc\Projects\test\node_modules\spawn-sync
> node postinstall
> yo@2.0.3 postinstall C:\Users\xxqqvc\Projects\test\node_modules\yo
> yodoctor
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
{ RequestError: connect ETIMEDOUT 104.18.97.96:443
at ClientRequest.req.once.err (C:\Users\xxqqvc\Projects\test\node_modules\latest-version\node_modules\got\index.js:73:21)
at Object.onceWrapper (events.js:273:13)
at ClientRequest.emit (events.js:182:13)
at TLSSocket.socketErrorListener (_http_client.js:382:9)
at TLSSocket.emit (events.js:182:13)
at emitErrorNT (internal/streams/destroy.js:82:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
at process._tickCallback (internal/process/next_tick.js:63:19)
code: 'ETIMEDOUT',
message: 'connect ETIMEDOUT 104.18.97.96:443',
host: 'registry.npmjs.org',
hostname: 'registry.npmjs.org',
method: 'GET',
path: '/yo' }
× yo version
{ RequestError: connect ETIMEDOUT 104.18.97.96:443
at ClientRequest.req.once.err (C:\Users\xxqqvc\Projects\test\node_modules\latest-version\node_modules\got\index.js:73:21)
at Object.onceWrapper (events.js:273:13)
at ClientRequest.emit (events.js:182:13)
at TLSSocket.socketErrorListener (_http_client.js:382:9)
at TLSSocket.emit (events.js:182:13)
at emitErrorNT (internal/streams/destroy.js:82:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
at process._tickCallback (internal/process/next_tick.js:63:19)
code: 'ETIMEDOUT',
message: 'connect ETIMEDOUT 104.18.97.96:443',
host: 'registry.npmjs.org',
hostname: 'registry.npmjs.org',
method: 'GET',
path: '/yo' }
× yo version
Your yo version is outdated.
Upgrade to the latest version by running:
npm install -g yo@latest
(node:6016) UnhandledPromiseRejectionWarning: Error: callback() can only be called once.
at onetime (C:\Users\xxqqvc\Projects\test\node_modules\each-async\node_modules\onetime\index.js:15:11)
at rule.verify.err (C:\Users\xxqqvc\Projects\test\node_modules\yeoman-doctor\lib\index.js:23:7)
at binVersionCheck.then (C:\Users\xxqqvc\Projects\test\node_modules\yeoman-doctor\lib\rules\yo-version.js:21:23)
at process._tickCallback (internal/process/next_tick.js:68:7)
(node:6016) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:6016) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
√ npm version
Found potential issues on your machine :(
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN test@1.0.0 No description
npm WARN test@1.0.0 No repository field.
+ yo@2.0.3
added 535 packages from 262 contributors and audited 1892 packages in 281.485s
found 0 vulnerabilities
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 36 (9 by maintainers)
Here’s this FIX for the proxy issue: as per the global-agent README.md, you must set env var: export GLOBAL_AGENT_HTTP_PROXY=http://proxy_server:proxy_port Issue resolved! Why was this buried in that README file!?!
I managed to get it to pass by running
yo doctorusingnpx.Interesting. So yeoman uses
global-agent, good to know. If you manage to set env varGLOBAL_AGENT_ENVIRONMENT_VARIABLE_NAMESPACEto an empty value, which is impossible from cmd but easy from node (process.env.GLOBAL_AGENT_ENVIRONMENT_VARIABLE_NAMESPACE="";), your standard HTTP_PROXY settings will be used. Note, I didn’t try any of this with yeoman.Hi, I am still having issues with this. I have set http_proxy, proxy and https_proxy environment variables + the npm http-proxy, proxy and https-proxy conf settings globally + the GLOBAL_AGENT_HTTP_PROXY env var (tried with HTML URL encoding and without).
yo doctorworks fine once GLOBAL_AGENT_HTTP_PROXY is set butnpm i yospends way too much time waiting for the yo version.Normally this wouldn’t be too much of an issue but this is impacting my Gitlab CI builds a lot as I use frontend-maven-plugin to do a npm install before every script. My build lasts for 20mn instead of maybe 3.
Could you please make the postinstall script use global-tunnel as well please ? @SBoudrias
@tremblaysimon thanks a lot for your help!
Other modules have Postinstall scripts that are importants. I want only to disable this Postinstall one. I’ve look in the code source and there’s no way to disable it. An env var check might be added for example to do this YO_DOCTOR_DISABLE for example
Perhaps you might remove this Postinstall step and let people decide to run it or not through the Postinstall of theirs module. When we work over a controlled environment, we don’t care all of these checks
I encountered the same problem here. With @MarcoScabbiolo post (enable some debugging information for global-tunnel library) I saw that problem:
It’s because for some reason I forgot to specify protocol for my proxy environment variables. Here what it’s look like:
after I fixed that problem (added http protocol), it works perfectly!
Now my environment variables for proxy are:
I don’t know if it’s a correct behavior from that library (global-tunnel) for not assuming any protocol…
In the end, I think we can close that bug if other people can confirm that their proxy environment variables wasn’t set properly like me…
Had the same problem, I think it is a dodgy proxy, the following worked for me…
npm config set registry=http://registry.npmjs.org/ npm config set strict-ssl false
Found here… https://stackoverflow.com/questions/33162560/error-tunneling-socket-could-not-be-established-cause-connect-econnrefused-10
If you’re running Node and NPM behind a corporate proxy I’m assuming you’ve set the proxy url in the npm configuration using one of the following:
Try PR #590 , it should recognize your proxy from these configurations automatically.
You can also set the proxy url in the
https_proxyorhttp_proxyenvironment variables.