fix: wait for new version of old package

[ascorbic]

Which problem is this pull request solving?

Often there is a delay before a published package is available on npm. Currently this action attempts to deal with this by retrying if there is an error. However it only catches this for newly-published packages, not new versions of existing packages.

Describe the solution you've chosen

This PR changes the code to catch this situation by handling not just HTTP errors (missing new packages return a 404), but also ETARGET errors which mean missing version.

Describe alternatives you've considered

Example: Another solution would be [...]

Checklist

Please add a x inside each checkbox:

• I have read the contribution guidelines.
• The status checks are successful (continuous integration). Those can be seen below.

A picture of a cute animal (not mandatory but encouraged)

[MarcL]

Looks good but should we add some tests around this?

[ascorbic]

I don't know how :( Testing GitHub Actions is a mystery to me

[MarcL]

Could we test the validatePackage code as a unit test with mocked network request instead?

[ascorbic]

Sounds like a good approach

[MarcL]

I had a quick dig into this last night for you @ascorbic to see how we could best unit test it.
With the way that pWaitFor waits for the internal function promise to resolve or throw, it's not so easy to test the internal code in a clean way.

I wrote an example test like this:

test.serial('should throw an error if package is created but not yet published', async (t) => {
  const fakeUnpublishedError : Error & { statusCode?: number; code?: string } = new Error('Package not yet published');
  fakeUnpublishedError.statusCode = 404

  sandbox.stub(pacote, 'manifest').rejects(fakeUnpublishedError)

  await t.notThrowsAsync(validatePackage('netlify/next-runtime', '1.0.0'))

  const stub = pacote.manifest as SinonStub
  sandbox.assert.notCalled(stub)
})

but the issue is that pWaitFor will continue checking until it resolves/throws or times out.

Suggestions which could help:

• we export the internal function and test that - but then we're exposing internals that we shouldn't need to know about
• we mock the time functions using sinon.fakeTimers to tick the timer on by WAIT_TIMEOUT - again, not keen on this as we'd have to assert that we tried to retrieve the manifest a couple of times with no easy way to see that the new code you added was tested.

Any thoughts? I don't want to block this PR with overly complicated testing.
I feel like exposing the internal function would be the easiest way to test it but we are then exposing the internal API.