3.0.0-alpha.8
Run vue create on a computer configured with a corporate HTTP Proxy
(http_proxy and https_proxy environment variable are defined, everything else is working properly)
It should run as usual
vue create command hangs forever with no prompt at all.
Tested on Windows and Ubuntu.
Did it work with any earlier versions?
It's a bit difficult for me to simulate your actual environment, but it probably hangs here: https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli/lib/util/getVersions.js#L17
I don't quite know why though because axios does automatically handle https_proxy env variables.
I'll try to debug this at work. That's the first time I try v3 here, and it was working properly with v2.
Getting the following error with @vue/[email protected] for vue create my-app
ERROR Error: write EPROTO 101057795:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:openssl\ssl\s23_clnt.c:827:
Error: write EPROTO 101057795:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:openssl\ssl\s23_clnt.c:827:
at _errnoException (util.js:1024:11)
at WriteWrap.afterWrite [as oncomplete] (net.js:867:14)
Getting this error with @vue/[email protected] for vue create randomapp
ERROR Error: connect ETIMEDOUT
Error: connect ETIMEDOUT
at Object._errnoException (util.js:1003:13)
at _exceptionWithHostPort (util.js:1024:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1194:14)
Can confirm the same here using http proxy.
Experienced a similar problem on Windows without the hanging but with a ERROR: connect ECONNREFUSED.
Could solve the error by manually set HTTP_PROXY and HTTPS_PROXY. Then it became a Error: socket hang up.
After changing the line
https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli/lib/util/getVersions.js#L15
to http://registry.npmjs.org I still get the same error, but through the line
https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli/lib/util/installDeps.js#L19
which could be solved by npm config set registry http://registry.npmjs.org/
I hope nobody mind my question: In https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli/lib/util/installDeps.js#L46 the user settings are respected. In https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli/lib/util/getVersions.js#L17 not. Is there a purpose to do that?
Maybe it's related to this axios issue : https://github.com/axios/axios/issues/925
If this is an axios issue we can switch to a different HTTP client. Can anyone try it out? I don't have the network environment to confirm whether that would fix it.
I'm going to give it a try tomorrow and providing feedback.
Maybe https://github.com/request/request ? It's stated in the axios issue that this use case works out of the box with request.
Have verified changing out request works in my environment. Unless someone else is already working on this I will put together a PR.
Thanks @wadetandy !
Code changes look good to me. Can someone else in this thread try out https://github.com/vuejs/vue-cli/pull/829 to see if that fixes it for you?
Going to check this in the morning, but's looking good.
Thanks, it's working fine now for me !
Also thanks, it's working for me too. At least if I hadn't muddled up some settings for our proxy :/
i'm getting this error using @vue/[email protected] for vue create randomApp
ERROR RequestError: Error: connect ETIMEDOUT 151.101.92.162:443
RequestError: Error: connect ETIMEDOUT 151.101.92.162:443
at new RequestError (C:\Users\myUser\AppData\Roaming\npm\node_modules\@vue\cli\node_modules\request-promise-core\lib\errors.js:14:15)
at Request.plumbing.callback (C:\Users\myUser\AppData\Roaming\npm\node_modules\@vue\cli\node_modules\request-promise-core\lib\plumbing.js:87:29)
at Request.RP$callback [as _callback] (C:\Users\myUser\AppData\Roaming\npm\node_modules\@vue\cli\node_modules\request-promise-core\lib\plumbing.js:46:31)
at self.callback (C:\Users\myUser\AppData\Roaming\npm\node_modules\@vue\cli\node_modules\request\request.js:186:22)
at Request.emit (events.js:160:13)
at Request.onRequestError (C:\Users\myUser\AppData\Roaming\npm\node_modules\@vue\cli\node_modules\request\request.js:878:8)
at ClientRequest.emit (events.js:160:13)
at TLSSocket.socketErrorListener (_http_client.js:389:9)
at TLSSocket.emit (events.js:160:13)
at emitErrorNT (internal/streams/destroy.js:64:8)
This workaround work for me..
I have to modified manually the request.js and indicate proxy as part of reqOpts. It doesn't seem to respect the environment variables that I have.
const request = require('request-promise-native')
module.exports = {
async get (uri) {
const reqOpts = {
method: 'GET',
resolveWithFullResponse: true,
json: true,
uri,
proxy: 'http://{domain}%5cu{username}:{pass}@proxy.company.com:8080'
}
return request(reqOpts)
}
}
@jnal What variables are you using to set proxy normally?
i have all the variables below set in .npmrc but that doesn't seem to be respected by the request.
proxy=http://{domain}%5cu{username}:{pass}@proxy.company.com:8080
https-proxy=http://{domain}%5cu{username}:{pass}@proxy.company.com:8080
http-proxy=http://{domain}%5cu{username}:{pass}@proxy.company.com:8080
HTTP_PROXY=http://{domain}%5cu{username}:{pass}@proxy.company.com:8080
HTTPS_PROXY=http://{domain}%5cu{username}:{pass}@proxy.company.com:8080
ignore-ssl=true
strict-ssl=false
some of the settings above might be invalid but I had them anyway just to make sure I am not missiing anything. also in environment variables
HTTP_PROXY=http://{domain}%5cu{username}:{pass}@proxy.company.com:8080
HTTPS_PROXY=http://{domain}%5cu{username}:{pass}@proxy.company.com:8080
also I'm using windows 10, node 8.9.4 and npm 5.6.0 if that helps
Did this ever get fixed? I am on 3.0.0 beta 10 and I still can't use vue create behind my corporate proxy.
@DrDanRyan this issue was resolved for me and a few others when my pr #829 was merged.
@wadetandy , how do I get a release with you PR in it? Version numer? Or does dev branch feed NPM directly? (tried an failed with beta 15)
My fix was merged and released with 3.0.0-alpha.10, so should be part of latest beta/RC.
And I have confirmed as it is working for me with those releases. May be a related but separate bug affecting you.
Most helpful comment
Have verified changing out request works in my environment. Unless someone else is already working on this I will put together a PR.