-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace URL.canParse()
with better supported code
#80
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
return URL.canParse?.(url) ?? (new URL(url) ? true : false)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be clear, I didn't suggest to remove the try catch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@@ -12,6 +12,6 @@ jobs: | |||
- name: Use Node.js | |||
uses: actions/setup-node@v1 | |||
with: | |||
node-version: "18.x" | |||
node-version: "18.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you pin it ? I have read your explanation, but I don't understand more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, that's a clever move. Thanks for explanation.
URL.canParse was only pretty recently created, and is not available in many environments.
We can instead wrap a
URL
creation 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.