Open jvivs opened 6 years ago
I'm also seeing this issue on every first installation, but it's not occurring on subsequent installs.
Something that stands out is the line at the end of @jvivs's request
logs:
[----------------------------------------] 29012347/Infinity 0% 0.0s^C
I have a similar line in my output:
[----------------------------------------] 31710606/Infinity 0% 0.0sUnpacking it into `./`
Maybe the ZIP file at https://codeload.github.com/unicode-cldr/cldr-numbers-modern/zip/31.0.1 is corrupted somehow?
I get a similar error at the same line.
throw error; ^
Error: connect ETIMEDOUT 192.30.253.112:443 at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14) npm WARN globalize-webpack-plugin@2.1.0 requires a peer of webpack@^3.0.0 but none is installed. You must install peer dependencies yourself. npm WARN skip-amd-webpack-plugin@0.2.0 requires a peer of webpack@^1.9.0 || ^2.2.0 || ^3.0.0 but none is installed. You must install peer dependencies yourself.
I get the same error. Your librairy is embedded into the new ecommerce storefront boilerplate from Salesforce. And a lot of user will be in trouble with this issue :/
Running download script manually worked for me:
./node_modules/cldr-data-downloader/bin/download.sh -i ./node_modules/cldr-data/urls.json -o ./node_modules/cldr-data/
yarn
Hi, for the Windows users, this is the syntax...
npm install cldr-data-downloader
node ./node_modules/cldr-data-downloader/bin/download.js -i http://www.unicode.org/Public/cldr/26/json.zip -o ./cldr
This added cldr-data-downloader
to package.json and created a cldr
folder within the root folder of my application and filled it with files.
However, this did not resolve the problem for me and it still kept bombing with a local certificate error for which the usual fix...
npm config set strict-ssl=false
...did not work.
In the end, I found that a bombing installation did not stop the app from running.
We have this issue in our CI environment:
npm ERR! \node_modules\cldr-data-downloader\lib\download.js:119 npm ERR! throw error; npm ERR! ^ npm ERR! npm ERR! Error: connect ETIMEDOUT *.82.121.3:443
Doing something manually here is not really an option for us...
Is there any workaround available? (maybe increasing the timeout?)
A fix is welcome, in case someone has bandwidth to provide one. Thank you all.
I don't know the reason but switching the network connection fixed the issue for me
In Mac OS, i had same issue, but when i remove Virus Security filter Network Content. I passed error. Maybe problem in network firewall or Internet Security Virus tool. Also Thanks @NiroshanKJ
GET `https://github.com/unicode-cldr/cldr-units-modern/archive/32.0.0.zip`
[========================================] 31967630/31967630 100% 0.0s
Received 31218K total.
No matter how I change the network, I'm always getting the error
GET `https://github.com/unicode-cldr/cldr-misc-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-numbers-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-segments-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-units-modern/archive/36.0.0.zip`
Whops Error making request.
Error: error request aborted
at createError (/xxx/node_modules/axios/lib/core/createError.js:16:15)
at IncomingMessage.handlerStreamAborted (/Users/xxx/git/xxx/node_modules/axios/lib/adapters/http.js:301:18)
at IncomingMessage.emit (events.js:400:28)
at TLSSocket.socketCloseListener (_http_client.js:432:11)
at TLSSocket.emit (events.js:412:35)
at net.js:686:12
at TCP.done (_tls_wrap.js:564:7)
Please report this full log at https://github.com/rxaviers/cldr-data-downloader
same..
GET https://github.com/unicode-cldr/cldr-numbers-modern/archive/36.0.0.zip
GET https://github.com/unicode-cldr/cldr-segments-modern/archive/36.0.0.zip
GET https://github.com/unicode-cldr/cldr-units-modern/archive/36.0.0.zip
Whops Error making request.
Error: error request aborted
at createError (/Users/xxx/Developer/reservamos-transporters/node_modules/axios/lib/core/createError.js:16:15)
at IncomingMessage.handlerStreamAborted (/Users/xxx/Developer/xxx/node_modules/axios/lib/adapters/http.js:301:18)
at IncomingMessage.emit (events.js:375:28)
at TLSSocket.socketCloseListener (_http_client.js:432:11)
at TLSSocket.emit (events.js:387:35)
at net.js:675:12
the same error:
[INFO] GET "https://github.com/unicode-cldr/cldr-units-modern/archive/36.0.0.zip" [INFO] D:\works\java\radixIot\ma-dashboards\UI\node_modules\cldr-data-downloader\lib\download.js:119 [INFO] throw error; [INFO] ^ [INFO] [INFO] Error: read ECONNRESET [INFO] at TLSWrap.onStreamRead (node:internal/stream_base_commons:220:20) { [INFO] errno: -4077, [INFO] code: 'ECONNRESET', [INFO] syscall: 'read' [INFO] }
Now using node v14.21.1 (npm v6.14.17)
I see the same error today...
GET `https://github.com/unicode-cldr/cldr-core/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-dates-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-buddhist-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-chinese-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-coptic-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-dangi-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-ethiopic-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-hebrew-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-indian-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-islamic-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-japanese-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-persian-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-cal-roc-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-localenames-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-misc-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-numbers-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-segments-modern/archive/36.0.0.zip`
GET `https://github.com/unicode-cldr/cldr-units-modern/archive/36.0.0.zip`
Whops Error making request.
Error: read ECONNRESET
at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20)
Please report this full log at https://github.com/rxaviers/cldr-data-downloader
Whenever I try and run npm install locally I get this error. Running it through our pipelines has always worked fine, but today I got the error on there as well. Re-ran the job and it was OK again. Very strange.
Any update on this or a workaround?
Hey everyone, I found a fix for my repository
This works specifically for pipelines:
Change npm install
to npm ci
This way it will only build what is specified in package-lock.json. it's also much faster for pipelines and best practice apparently
This stopped the socket errors for me and cut the time considerably
Having difficulty successfully installing the
cldr-data
package and its raising the following error fromcldr-data-downloader
:Platform information: macOS 10.12.6
cldr-data@31.0.1
cldr-data-downloader@0.3.2
node@8.9.4
npm@5.6.0
yarn@1.5.1
I have run into this issue with the downloader in the past, but it has been chugging along for the past ~6mos or so without much of a hiccup until today. My success rate today is ~5%.
When I try to download what seems to be the offending
cldr
zip (https://github.com/unicode-cldr/cldr-units-modern/archive/31.0.1.zip), the browser completes the download just fine.I've done a bit of digging around in both
cldr-data-downloader
andrequest
to try and get a better picture of what's going on. Investigation shows that request appears to be getting a 200, closing the connection, and emitting thecomplete
event, but the downloader still does not not finish successfully:(end of output
NODE_DEBUG=request npm run install
from insidenode_modules/cldr-data
)I also get the above result when attempting to install or upgrade a dependency with
yarn
, bootstrapping withlerna
(usingyarn
+ workspaces under the hood), or installing withnpm
.One thing that does seem to stick out to me is that the final bytes counted by
request-progress
may don't seem to be accurate or indicative of a successful download or not.Does this jog anyone's memory?