fix(Bandcamp): Fall back to raw release URL for custom domains

[mwiencek]

I got an error trying to import https://ponyband.bandcamp.com/track/haunted-house-remix-feat-mspaint:

No provider returned a release
Bandcamp: Failed to extract ID from https://ponytheband.ca/

The custom domain stood out to me, and I was worried I broke something related to those in #7, so I found another /album/ with a custom domain and tested it on the v2024.5.26 tag: https://zoekeating.bandcamp.com/album/snowmelt-ep

That gave a similar error on the v2024.5.26 tag, so the issue isn't related to my patch.

I dug into the code to see how custom domains are handled, and found that it attempts to retrieve the actual Bandcamp URL from the packages array. However, neither of the releases above have any packages, so this fails.

This commit caches the raw release URL we construct in getRawRelease as an alternative fallback.

Questions: Is there a reason this.rawReleaseUrl would be incorrect in some cases? Is the packages fallback still needed?

[kellnerd]

Good catch, this finally proves that there is no reliable way to extract the Bandcamp release URL from the embedded JSON.

Is there a reason this.rawReleaseUrl would be incorrect in some cases? Is the packages fallback still needed?

The packages fallback can be removed.

Originally I tried to avoid constructing the URL from the lookup options in case there will ever be an alternative way to lookup a Bandcamp release (e.g. by GTIN).
But if that ever happens we have to find another way to obtain the release URL anyway.

[atj]

Bandcamp no longer seems to support custom domains aside from performing a redirect to the relevant bandcamp.com sub-domain. I believe this is due to the planned phasing out of third-party cookies in Chrome.

Unfortunately the metadata still includes the custom domain instead of the bandcamp.com URL, but the latter should always be treated as canonical IMO.

[mwiencek]

Yeah, I noticed they all just redirect, and certainly wouldn't trust the stability of them in the long term. I think you're right about 3rd party cookies.

Updated this to remove the packages fallback. @kellnerd, if you'd like to avoid the non-null assertion, I could probably just change it to call constructReleaseUrl again.

[kellnerd]

if you'd like to avoid the non-null assertion, I could probably just change it to call constructReleaseUrl again.

Thanks, but it is fine as is, not worth to repeat work just to make TS happier.