Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 34.2k
esm: avoid try/catch when validating urls#47541
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
Conversation
nodejs-github-bot commented Apr 13, 2023
Review requested:
|
aduh95 left a comment • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
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.
Given that URL.canParse is user-mutable, should we use const{canParse } = URL or something like that? Or even better, can we import it primordial-style from ada directly?
anonrig commented Apr 13, 2023
@aduh95 I like where this is going, but I couldn't visualize it. Can you elaborate on how we can import it primordial-style? We can always do |
aduh95 commented Apr 13, 2023
Yes, I mean something that's available only internally and cannot be mutated at runtime. |
5375959 to 3a57762Comparenodejs-github-bot commented Apr 13, 2023
ljharb commented Apr 13, 2023
This is way better/cleaner :-) but does it prevent backporting this commit, since older release lines may not have URL.canParse? |
anonrig commented Apr 13, 2023
It might make it harder, due to conflicts, but I don't think it will block backporting any future changes to ESM. |
ljharb commented Apr 13, 2023
oh sure, i just meant, should this PR have any "do not backport" labels, or link to the canParse PR as a prereq? |
anonrig commented Apr 13, 2023
I'm not quite sure. @nodejs/releasers what do you recommend? |
JakobJingleheimer left a comment
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.
Sweet, thanks! I was just suggesting this change last night in Slack 😁
aduh95 commented Apr 13, 2023
|
mscdex commented Apr 13, 2023
I'm confused by this. The C++ API still says this: Lines 116 to 117 in 4afb25c
Or did you actually mean this PR does not improve performance until the TODO is resolved? |
anonrig commented Apr 13, 2023
I was giving some context to this particular change. It is definitely faster than the current implementation. Additionally, @KhafraDev just opened a pull request for adding v8 fast API to |
ljharb commented Apr 13, 2023
@aduh95 perfect, thanks for clarifying and linking :-) |
3a57762 to 05742e9Comparenodejs-github-bot commented Apr 14, 2023
nodejs-github-bot commented Apr 14, 2023
anonrig commented Apr 14, 2023
Would someone re-review this pull request? It's required due to force-push. |
| }=require('internal/errors').codes; | ||
| const{exitCodes: { kUnfinishedTopLevelAwait }}=internalBinding('errors'); | ||
| const{URL}=require('internal/url'); | ||
| const{canParse: urlCanParse}=internalBinding('url'); |
JakobJingleheimerApr 15, 2023 • edited
Loading Uh oh!
There was an error while loading. Please reload this page.
edited
Uh oh!
There was an error while loading. Please reload this page.
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.
nit: this sounds a little Yoda-esque
| const{canParse: urlCanParse}=internalBinding('url'); | |
| const{canParse: canParseURL}=internalBinding('url'); |
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.
Not sure this is better, isURLString might be more suited. URLCanParse has the upside of being consistent with how primordials are named, which is nice imho
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 want to change this to URLCanParse too but I'm too demotivated by having to run Node.js CI multiple times because of the flaky tests.
nodejs-github-bot commented Apr 15, 2023
Landed in 17570c0 |
PR-URL: #47541 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Jacob Smith <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>
PR-URL: nodejs#47541 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Jacob Smith <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>
PR-URL: #47541 Backport-PR-URL: #50669 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Jacob Smith <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>
PR-URL: nodejs/node#47541 Backport-PR-URL: nodejs/node#50669 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Jacob Smith <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>
PR-URL: nodejs/node#47541 Backport-PR-URL: nodejs/node#50669 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Jacob Smith <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Stephen Belanger <[email protected]>
Due to
URL.canParse, we can avoid try/catch block and have faster validation. The previous implementation was not performant due to:href,originetc. for validating if a URL is valid or not.URL.canParsecan be written with V8 Fast API - enabling more performance out of this pull request.URL.canParsedoes not return anything except a boolean.cc @nodejs/url