-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
Begin docs-deprecation of fs.readdir{Sync}()
, add fs.scandirSync()
alias.
#36008
Conversation
This is a follow-up to nodejs#29349 and a precursor to deprecating both `fs.readdir()` and `fs.readdirSync()`. This also updates the documentation which has been incorrect for some 10 years saying that these did `readdir(3)` when in reality they do `scandir(3)`. Only `scandirSync()` is introduced as "async scandir(3)" is kind of a trap, given that it returns the whole list of entries at once, regardless of how many there are. Since in many cases we'd also want to get dirents for them (i.e. `stat`-ing each and every one), this becomes a serious problem, and Node.js should encourage users to use `fs.opendir()`, which is slightly more complex but far better.
It's time overdue for these to start going away. `fs.opendir()` was introduced over a year ago in nodejs#29349 - which stated a follow-up of: "Aliasing fs.readdir to fs.scandir and doing a deprecation." This provides the intial docs deprecation to both `fs.readdir()` and `fs.readdirSync()`, both of which are misnamed, and the former of which is a trap as it is not fully async.
<!-- YAML | ||
changes: | ||
- version: REPLACEME | ||
pr-url: REPLACEME |
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.
pr-url: REPLACEME | |
pr-url: https://github.com/nodejs/node/pull/36008 |
where possible, otherwise use [`fs.opendir()`][]. | ||
`fs.readdir()` is not fully asynchronous. It is asynchronous while gathering | ||
the list of directory entries but then sends them to JavaScript as one large | ||
array. In cases where this array contains hndreds of entries, particularly if |
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.
array. In cases where this array contains hndreds of entries, particularly if | |
array. In cases where this array contains hundreds of entries, particularly if |
@@ -2750,9 +2781,14 @@ runtime warning results no matter where the `"exports"` usage occurs. | |||
[`fs.lchmodSync(path, mode)`]: fs.md#fs_fs_lchmodsync_path_mode | |||
[`fs.lchown(path, uid, gid, callback)`]: fs.md#fs_fs_lchown_path_uid_gid_callback | |||
[`fs.lchownSync(path, uid, gid)`]: fs.md#fs_fs_lchownsync_path_uid_gid | |||
[`fs.opendir()`]: fs.html#fs_fs_opendir_path_options_callback |
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.
[`fs.opendir()`]: fs.html#fs_fs_opendir_path_options_callback | |
[`fs.opendir()`]: fs.md#fs_fs_opendir_path_options_callback |
@@ -6125,6 +6152,7 @@ the file contents. | |||
[`fs.readv()`]: #fs_fs_readv_fd_buffers_position_callback | |||
[`fs.realpath()`]: #fs_fs_realpath_path_options_callback | |||
[`fs.rmdir()`]: #fs_fs_rmdir_path_options_callback | |||
[`fs.scandirSync()`]: fs.html#fs_fs_scandirsync_path_options |
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.
[`fs.scandirSync()`]: fs.html#fs_fs_scandirsync_path_options | |
[`fs.scandirSync()`]: #fs_fs_scandirsync_path_options |
@@ -3011,13 +3015,15 @@ changes: | |||
protocol. Support is currently still *experimental*. | |||
--> | |||
|
|||
> Stability: 0 - Deprecated. Use [`fs.scandirSync()`][] instead. |
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.
There shoud be a deprecated: REPLACEME
in the YAML above.
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 would prefer not to do this, apart from explicitly recommending fs.promises.opendir()
…
I don’t think readdir()
is misnamed enough to justify deprecating it and adding it under a different name (and in my subjective opionion, readdir()
is a clearer name than scandir()
even), and I also don’t think that using fs.readdir()
is inherently a bad thing to use, as the case of directories with more than a few dozen entries is extremely rare in practice.
|
||
[`fs.readdir()`][] is deprecated. Use [`fsPromises.opendir()`][] instead, | ||
where possible, otherwise use [`fs.opendir()`][]. | ||
`fs.readdir()` is not fully asynchronous. It is asynchronous while gathering |
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.
How is fs.readdir()
not fully asynchronous? That seems inaccurate
This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open. |
Closing this because it has stalled. Feel free to reopen if this PR is still relevant, or to ping the collaborator who labelled it stalled if you have any questions. |
It's time overdue for these to start going away.
fs.opendir()
was introduced over a year ago in #29349 - which stated a follow-up of: "Aliasing fs.readdir to fs.scandir and doing a deprecation."This provides the intial docs deprecation to both
fs.readdir()
andfs.readdirSync()
, both of which are misnamed, and the former of which is a trap as it is not fully async.This also contains an addition of
fs.scandirSync()
, also a follow-up to #29349 and a precursor to deprecating bothfs.readdir()
andfs.readdirSync()
.This also updates the documentation which has been incorrect for some 10 years saying that these did
readdir(3)
when in reality they doscandir(3)
.Only
scandirSync()
is introduced as "async scandir(3)" is kind of a trap, given that it returns the whole list of entries at once, regardless of how many there are. Since in many cases we'd also want to get dirents for them (i.e.stat
-ing each and every one), this becomes a serious problem, and Node.js should encourage users to usefs.opendir()
, which is slightly more complex but far better.A follow-up thought: Regarding a potential
fs.scandir()
, should people think it is in some way desirable for api parity, I believe it should be deprecated out of the gate, or warned against heavily in the docs.Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes