-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
fs: make FileHandle.readableWebStream
always create byte streams
#55461
base: main
Are you sure you want to change the base?
Conversation
0e81802
to
57bfbb3
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #55461 +/- ##
==========================================
- Coverage 88.41% 88.41% -0.01%
==========================================
Files 652 654 +2
Lines 186918 187855 +937
Branches 36077 36145 +68
==========================================
+ Hits 165271 166095 +824
- Misses 14901 15000 +99
- Partials 6746 6760 +14
|
57bfbb3
to
88496b4
Compare
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.
Sorry again for the butchering of my last comment.
Here's my idea to gracefully make users aware of this change. We start by warning that this option has no effect, and then in the next semver, we remove the warning entirely.
Assuming this lands in 23.X.0, we can remove the warning in 23.(X + 1).0 Although, because this is experimental, a warning isn't technically required, so you have the final say (IMO) whether there is one to add |
88496b4
to
d747a6f
Compare
Edit: Sorry, it's already marked as such!
|
d747a6f
to
946019e
Compare
@RedYetiDev can you take another look? |
946019e
to
86a1021
Compare
The original implementation of the experimental `FileHandle.readableWebStream` API created non-`type: 'bytes'` streams, which prevented callers from creating `mode: 'byob'` readers from the returned stream, which means they could not achieve the associated "zero-copy" performance characteristics. Then, nodejs#46933 added a parameter allowing callers to pass the `type` parameter down to the ReadableStream constructor, exposing the same semantics to callers of `FileHandle.readableWebStream`. But there is no point to giving callers this choice: FileHandle-derived streams are by their very nature byte streams. We should not require callers to explicitly opt in to having byte stream semantics. Moreover, I do not see a situation in which callers would ever want to have a non-bytes stream: bytes-streams only do anything differently than normal ones if `mode: 'byob'` is passed to `getReader`. So, remove the `options` parameter and always create a ReadableStream with `type: 'bytes'`. Fixes nodejs#54041.
86a1021
to
41c448c
Compare
The original implementation of the experimental
FileHandle.readableWebStream
API created non-type: 'bytes'
streams, which prevented callers from creatingmode: 'byob'
readers from the returned stream, which means they could not achieve the associated "zero-copy" performance characteristics.Then, #46933 added a parameter allowing callers to pass the
type
parameter down to the ReadableStream constructor, exposing the same semantics to callers ofFileHandle.readableWebStream
.But there is no point to giving callers this choice: FileHandle-derived streams are by their very nature byte streams. We should not require callers to explicitly opt in to having byte stream semantics. Moreover, I do not see a situation in which callers would ever want to have a non-bytes stream: bytes-streams only do anything differently than normal ones if
mode: 'byob'
is passed togetReader
.So, remove the
options
parameter and always create a ReadableStream withtype: 'bytes'
.Fixes #54041.