Repository navigation
[BUG] Couldn't find any versions for "core-js" that matches "3.4.7" #545
Description
What / Why
❯ npm i -s core-js
+ core-js@3.4.6
updated 1 package and audited 1 package in 0.571s
found 0 vulnerabilities
But on the npm registry website it shows core-js@3.4.7 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 core-js@3.4.7
Who
- n/a
References
- n/a
Reacted by Oleg Stepura, Nicolò Ribaudo, Luis Fernando López Ruiz, Joe Haddad, Rowan Cockett, Simon Tretter, Johan, Galilea Valle , Chris, Daniel Almaguer and 29 more
Reacted by Evan Gray
Activity
dcwarwick commentedon Dec 2, 2019
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.
esetnik commentedon Dec 2, 2019
@dcwarwick it must be a caching bug. The registry shouldn't be advertising 3.4.7 and serving 3.4.6 as latest...
icleolion commentedon Dec 2, 2019
Seems to have fixed itself now.
npm ijust pulled through 3.4.7 for me.darcyclarke commentedon Dec 2, 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-jsseems to confirm that latest is3.4.7)esetnik commentedon Dec 2, 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.
nicolo-ribaudo commentedon Dec 2, 2019
Yeah this seems to be fixed for me.
ahmadnassri commentedon Dec 2, 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.
esetnik commentedon Dec 2, 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?
ahmadnassri commentedon Dec 3, 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.
mikemimik commentedon Dec 4, 2019
I've labelled this issue as 'Wontfix' as it does not concern the cli repository. Thanks for bringing this to our attention though 👍