Replace URL.canParse() with better supported code

[aloisklink]

URL.canParse was only pretty recently created, and is not available in many environments.

We can instead wrap a URL creation in a try..catch, as listed in MDN. Unfortunately, this is a bit slower, but at least it works almost everywhere:

This is a fast and easy alternative to constructing a URL within a try...catch block.

Taken from https://github.com/mdn/content/blob/392ce991114e55e2187510b640ab545d09258a16/files/en-us/web/api/url/canparse_static/index.md?plain=1#L13

Fixes #78

---

I've also updated the CI to run on Node.JS v18.0, instead of Node.JS v18.x. This is because #78 would have caught this issue, as URL.canParse() was only added in Node.JS v18.17.

[aloisklink]

If it helps, @ibooker said in #78 (comment) that this bug has an internal tracking ID of BTWEB-171.

[dcousens]

return URL.canParse?.(url) ?? (new URL(url) ? true : false)

[aloisklink]

This won't work, since new URL(url) throws an exception if it fails, so it needs to be wrapped in a try..catch.

But, we could do something like:

  if (URL.canParse) {
    return URL.canParse(url);
  }
  try {
    // We can replace this with URL.canParse() once it's more widely available
    new URL(url); // eslint-disable-line no-new -- We're only checking for exceptions
    return true;
  } catch (error) {
    return false;
  }

However, I'm not a fan of this. Sure, it's slightly faster in environments that do support URL.canParse, but the code is more complicated, and it's much harder to test, as we'd need environments that both support URL.canParse and don't support it.

[dcousens]

to be clear, I didn't suggest to remove the try catch

[dcousens]

I guess it's a useless suggestion though, when the documentation says:

It returns true for the same values for which the URL() constructor would succeed, and false for the values that would cause the constructor to throw.

If that holds true in perpetuity, then don't worry about my suggestion