Cli: [BUG] Couldn't find any versions for "core-js" that matches "3.4.7"
What / Why
❯ npm i -s core-js
+ [email protected]
updated 1 package and audited 1 package in 0.571s
found 0 vulnerabilities
But on the npm registry website it shows [email protected] as latest:
https://www.npmjs.com/package/core-js?activeTab=versions
When
2019-12-02 2:17:29PM EST
Where
npm public registry
How
Current Behavior
Couldn't find any versions for "core-js" that matches "3.4.7"
Steps to Reproduce
Try to install core-js
Expected Behavior
Should install [email protected]
Who
- n/a
References
- n/a
esetnik
All 10 comments
This is hitting a lot of people. core-js-compat was published in a broken state as 3.4.6, which is unfortunate but was quickly fixed as 3.4.7, but 3.4.6 is still (at time of posting this comment) being served out from npm even though it indicates that latest=3.4.7. If it's a caching problem it's really unfortunate that's it's caught a bad version and doesn't let the good version that fixes it through.
dcwarwick
on 2 Dec 2019
@dcwarwick it must be a caching bug. The registry shouldn't be advertising 3.4.7 and serving 3.4.6 as latest...
esetnik
on 2 Dec 2019
Seems to have fixed itself now. npm i just pulled through 3.4.7 for me.
icleolion
on 2 Dec 2019
@esetnik Can you please double check that and confirm that the proper version is now showing up on both .com & the registry? I believe this has been resolved (ex. running npm view core-js seems to confirm that latest is 3.4.7)
darcyclarke
on 2 Dec 2019
It is resolved now. Will you update https://status.npmjs.org to indicate that there was a service degradation during this time period? It shows no incidents even though many users were unable to download a popular package for several hours. It'd also be good to get some update from the npm team as to why this happened and what the plan is to address it.
esetnik
on 2 Dec 2019
Yeah this seems to be fixed for me.
nicolo-ribaudo
on 2 Dec 2019
@esetnik this was not a service degredation. We rely on CloudFlare for CDN delivery, and it seems you've just been hitting a cached edge node in the distributed CDN when hitting the CLI install path, vs the website caching.
ahmadnassri
on 2 Dec 2019
@ahmadnassri I don’t think this should be closed. There’s a technical issue with the npm platform if you aren’t proactively invalidating your edge caches when a new package is published. The result of this issue was that for several hours builds were failing and the package author couldn’t do anything because they had already published a working version that npm wasn’t serving to customers. Is this the expected behavior that new versions of packages may be unavailable for up to several hours after publish?
esetnik
on 3 Dec 2019
as this is the CLI repo, it's not useful to discuss registry operations here, feel free to send a support ticket if you require further clarification.
ahmadnassri
on 3 Dec 2019
I've labelled this issue as 'Wontfix' as it does not concern the cli repository. Thanks for bringing this to our attention though 👍
mikemimik
on 4 Dec 2019
Related issues
MadhuriGurumurthy11
·
3Comments
darcyclarke
·
3Comments
jaydenseric
·
3Comments
goldingdamien
·
4Comments
FaizenR
·
3Comments
Most helpful comment
Seems to have fixed itself now.
npm ijust pulled through 3.4.7 for me.