-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
esm: doc & validate source values for formats #32202
Conversation
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.
Looks good other than the docs note. Thanks for doing this!
doc/api/esm.md
Outdated
|
||
| `format` | Description | | ||
| `format` | Description | Acceptable Source Values | |
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.
Maybe it's just me, but I read this as "the source value of format
", e.g. that 'builtin'
should be a string. I think what you mean is the acceptable type of source
returned by getSource
for this format? So maybe call this "Acceptable Types for getSource
Returned source
"?
Should we also update the signature in getSource
?
@returns {string|buffer} response.source
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.
Yes, I meant the value from either getSource OR transformSource
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.
Okay, do you mind making that clearer? Maybe “Acceptable Types For source
Returned by getSource
or transformSource
”?
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.
done, also made sure to actually check both hooks rather than just transformSource
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.
Nice to see this being locked down well.
Do we need to update the JSDoc function signatures? e.g. @returns {string|buffer} response.source |
@bmeck ☝️ #32202 (comment) do we need to fix this too? |
@GeoffreyBooth We could, but overall the signature isn't trivial and I think |
rebased and looks green locally, will CI then land if green and no comment in next few hours |
44fcb28
to
a3a01f4
Compare
rebase had a minor change, in particular I had to update |
@bmeck Didn’t look into the other failures but at least the linter is complaining |
a3a01f4
to
cd5ccdf
Compare
Fixed lint, CI errors seem unrelated |
Test error without intl:
|
ae2427c
to
01af9cd
Compare
01af9cd
to
614ec8e
Compare
Co-authored-by: Derek Lewis <[email protected]>
Co-authored-by: Derek Lewis <[email protected]>
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.
Although much of this is new material to me, the previous layout didn't really make sense to me. :/
My suggestions are how I've made sense of it, but I could be wrong. I hope we can improve this little area, it's a rather important section for those implementing types on the function boundaries of the custom loader hooks API.
Co-authored-by: Derek Lewis <[email protected]>
Co-authored-by: Derek Lewis <[email protected]>
Co-authored-by: Derek Lewis <[email protected]>
PR-URL: #32202 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Zeyu Yang <[email protected]>
landed in cd4985c |
PR-URL: #32202 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Zeyu Yang <[email protected]>
PR-URL: #32202 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Geoffrey Booth <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: Zeyu Yang <[email protected]>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesThis better specifies how decoding of source values returned from loaders are translated. Some formats expect different types of sources. This also fixes some problems where Buffers were properly decoding due to the custom
.toString
but typed arrays were not.We could expand the tests if desired, but I felt just checking
Uint8Array
was sufficient.