Repository navigation
fs.readdir's new recursive option is not fully documented #48640
Description
Activity
- Reacted by Moshe Atlow
can i work on this?
Can you share the case where it doesn't work with
withFileTypes? I added a multitude of tests when I landed the option so I wanna know what I missedBtw it looks more like a bug than a documentation issue.
Reacted by Moshe Atlow, cypress evelyn masso and Chris ClarkBtw it looks more like a bug than a documentation issue.
No documentation is provided for
recursiveregardless, so I think it's still an issue. Maybe I should have filed the lack of documentation and the bug separately.@Ethan-Arrowood From further testing, I've found some behavior that varies between the promise, callback, and synchronous versions.
-
The promise version appears to not have any issues.
-
The callback and synchronous versions can generate a entry
Dirent { name: undefined, path: '...', [Symbol(type)]: undefined }, whenwithFileTypesis supplied, replacing a valid entry. -
The callback and synchronous versions fail to list certain files and directories when both
withFileTypesandrecursiveare provided. I noticed this as several entries under.gitmissing, I'm unsure what the cause is.Details
Note: Since nested directories themselves are not listed, these issues are likely not related to the recursion step as I had previously assumed, however this behavior is only present whenrecursiveis also supplied and is not present in previous versions (Tested on Node v18.16.1.). I will update the original message to reflect this.
A minor inconsistency I found is that when providing the results the promise version appears to act as depth-first, while the callback and synchronous versions act as breath-first in their resulting arrays.
These tests have been on a limited filetree which I've uploaded to
fs-readdir-recursive.-
Okay I can confirm there are two issues here.
First, missing documentation for the
recursiveoption for thecallbackandsyncversions.Second, I am seeing the
undefinedbehavior in thecallbackandsyncversions; I think your latest message @That-Guy977 explains it well. What I'm most intrigued by is how the tests aren't catching this. We definitely need to fix this. I'm going to start investigating this problem now.Finally, I do not believe the difference in search behavior matters. We make no guarantees in how Node recursively searches a directory. In a long historical thread I commented the possibility of specifying which algorithm could be used, but that is a feature not a bug in this case.
Some users here expressed interest in contributing, @pernelkanic you commented first. Would you like to work on the documentation fix?
Reacted by Chris Sophos and Christian Farías ÁguilaReacted by Moshe AtlowFirst, missing documentation for the
recursiveoption for thecallbackandsyncversions.I believe the promise version has the same lack of documentation, as it and the other versions are lacking a similar description as
opendirorrm, or even an explanation in the method description as is present inmkdir.Oh good point 👍 that should be fixed too then
9 remaining items
- added a commit that references this issue
on Aug 15, 2023 - added 2 commits that reference this issue
on Aug 16, 2023 - added a commit that references this issue
on Oct 10, 2023 - added a commit that references this issue
on Oct 28, 2023 - added a commit that references this issue
on Nov 11, 2023 - added a commit that references this issue
on Apr 15, 2024 - added 2 commits that reference this issue
on Apr 25, 2024
Affected URL(s)
https://nodejs.org/dist/latest-v20.x/docs/api/fs.html#fspromisesreaddirpath-options and callback/synchronous versions
Description of the problem
From testing, therecursiveoption does not work withwithFileTypes: true.The behavior of the
recursiveoption is not documented, and onlyrecursive's type and default value are present in the documentation. The callback-asyncfs.readdirand the synchronousfs.readdirSyncyield erraneous results (entries missing or appear with missing fields) when bothrecursiveandwithFileTypesare supplied.This issue tracks missing documentation. Incorrect behavior is tracked at #48858.