[BUG] Couldn't find any versions for "core-js" that matches "3.4.7"

[esetnik]

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

[dcwarwick]

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]

@dcwarwick it must be a caching bug. The registry shouldn't be advertising 3.4.7 and serving 3.4.6 as latest...

[icleolion]

Seems to have fixed itself now. npm i just pulled through 3.4.7 for me.

[darcyclarke]

@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)

[esetnik]

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]

Yeah this seems to be fixed for me.

[ahmadnassri]

@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]

@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]

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]

I've labelled this issue as 'Wontfix' as it does not concern the cli repository. Thanks for bringing this to our attention though 👍