Update for resolving tarball location of custom registries to support NPM clients

[bkaney]

This is a POC to fix assumptions when trying to download the tarball. See https://chat.fhir.org/#narrow/stream/179239-tooling/topic/NPM.20Registry

[cmoesel]

I like this. Thank you.

Before we can take it as-is, I think we need to determine if this is a valid approach for FHIR registry servers, as they don't document use of dist.tarball and instead specify the hard-coded URL pattern here.

[cmoesel]

Oh. And I'm sure it must break some tests too. So I guess we'd need to fix those up as well.

[bkaney]

Great! I can work on passing tests / linting / etc.

@cmoesel - do you think this should only apply with custom registries -- e.g. shall this part get reverted? https://github.com/standardhealth/fhir-package-loader/pull/16/files#diff-51cd61f2399d311debdd2c813260b4a799b0cd6155b8eaa0f1498aebdc5ca281L225-R239 -- then if the FHIR Package spec changes, it could be use for both.

[bkaney]

I decided to make that change, need to figure out how expectDownloadSequence works, and then should be able to get tests to pass.

[bkaney]

I had to modify expectDownloadSequence to indicate when a zipfile was expected (vs when it was not). This is ready to review now @cmoesel

[cmoesel]

Thanks for the PR, @bkaney! I like the approach!

I just found a couple of nit-picky things in the tests that I'd like updated if possible. Other than that, it looks good and works well. I tested it by exporting FPL_REGISTRY as https://registry.npmjs.org and then installing [email protected] (which Josh Mandel uploaded to NPM the other day). It worked as expected!

[bkaney]

@cmoesel - I think this is ready now, LMK if you see anything else.

[cmoesel]

Thank you, @bkaney! It looks great!

We usually require two reviews for PRs, so after someone else from our team reviews it, we'll get it merged!

[jafeltra]

This looks good to me! Thanks!