Replace URL.canParse() with better supported code#80
Conversation
[URL.canParse][1] 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. [1]: https://developer.mozilla.org/en-US/docs/Web/API/URL/canParse_static Fixes: braintree#78
This would have caught like braintree#78, as `URL.canParse()` was only added in Node.JS v18.17
|
If it helps, @ibooker said in #78 (comment) that this bug has an internal tracking ID of BTWEB-171. |
| 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 |
There was a problem hiding this comment.
return URL.canParse?.(url) ?? (new URL(url) ? true : false)There was a problem hiding this comment.
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.
There was a problem hiding this comment.
to be clear, I didn't suggest to remove the try catch
There was a problem hiding this comment.
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
| uses: actions/setup-node@v1 | ||
| with: | ||
| node-version: "18.x" | ||
| node-version: "18.0" |
There was a problem hiding this comment.
Why do you pin it ? I have read your explanation, but I don't understand more.
There was a problem hiding this comment.
It's because URL.canParse doesn't exist in Node.JS v18.0, since it was only added in Node.JS v18.17.
So this test will make sure that we don't accidentally add anything that breaks with old versions of Node.JS v18. (if we do, we'd ideally want to make a new MAJOR change and state that the minimum supported of Node.JS has changed in the release notes).
For example, Amazon Linux 2023 only comes with Node.JS v18.12.
There was a problem hiding this comment.
Oh, that's a clever move. Thanks for explanation.
|
closing this as this overlaps with #93 which is more recently updated and has tests |
URL.canParse was only pretty recently created, and is not available in many environments.
We can instead wrap a
URLcreation in atry..catch, as listed in MDN. Unfortunately, this is a bit slower, but at least it works almost everywhere: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.