Cannot install latest version of an npm package, possibly caching 4xx from NPM

This is a re-issue of #491, because the problem did not go away by itself.

Basically:

1. Add a package to a blitz
2. I think you need to attempt to install a new version explicitly before publishing or before publish has propagated. I am pretty sure I did that.
3. Publish a new version to NPM
4. StackBlitz cannot find the new version when you try to install it, explicitly or through an update.

Example blitz where this is happening:

• https://stackblitz.com/edit/angular-7fkpzq-y7hb79
• Has version ng2-dragula@2.0.1, we want to upgrade to ng2-dragula@2.0.2
• 2.0.2 was published 5 days ago, and the blitz is still stuck.
• I can install v2.0.2-0 just fine, explicitly or with the @next dist-tag.

Step 4 is impossible to achieve. Here are 3 ways you might try:

• If you refresh, it does not find the new version.
• If you delete and re-add, it does not find the new version.
• If you delete and re-add with an explicit version like ng2-dragula@2.0.2, the UI comes up with an error saying “Failure: unsatisfied version range. Unable to resolve package ng2-dragula@2.0.2”.

That Step 2 is necessary leads me to believe that StackBlitz/turbo is caching 4xx/5xx responses from NPM, which is wrong.

[EricSimons]

Man, seems like npm’s throttling/caching has gotten worse recently. We’re working on a fix- will post back when we’re close to shipping it

[markwhitfeld]

We are working on resolving this issue. Unfortunately the mechanisms that we relied on previously from npm are proving to be much less reliable than before. Currently it seems that the npmjs eventual consistency model has been increasing the “eventual” part of the approach. We have been running into issues where we receive a “webhook” call from them that a package has been updated and then when we go to update our cache, the new version is not yet available. As a result, our package resolution cache becomes one step behind. Previously this would happen very sporadically, but recently it is unfortunately becoming quite common. Resolving this is not as straightforward as it may seem from the outside. The caching mechanism is one of the key factors that enables the blistering speed that turbo has to offer and we cannot just call npm whenever we want to (we would very quickly be rate-limited). We are currently looking at ways that we can keep our cache consistently in sync with these constraints and will keep this issue updated with the progress.