fs/promises API inconsitency (.close not there) #20548
Closed
Description
Currently, fs/promises
provides a nearly identical API to fs
, minus callbacks → promises change (obvious) and the fd
→ filenandle
change (mostly invisible in most usecases).
The following parts of fs
API are not present on fs/promises
:
*Sync
methods (obvious)- non-functions (ok)
exists
— kinda ok, since it was deprecated and never worked in a promisified variant.access
is there.*Stream
— well, kinda ok, not a promise.*watch*
— also ok, it doesn't behave like promises.close
— why?
All the other methods, except close
, that are present on filehandle
objects and in callback-based fs
API are also present directly as methods of fs/promises
API, accepting a filehandle
. I assume that was done to ease the migration and provide 1:1 mapping between those where sensible, e.g. for people who were previously using promisified fs
versions.
I don't see how close
is different from other filehandle
APIs, so in my opinion either of there two should happen:
- All the methods of
fs/promises
that accept afilehandle
should be dropped in favor of the same methods onfilehandle
objects.
This will avoid overcomplicating things, will declutter the docs and will save time future users figuring out the «canonical» way to do something. fs/promises
should have as much of directfs
API duplicates as reasonable — basically, what we have now +.close
should be added.
This will ease migration for people who are already using the currentfs
API with (or without) promisify.
Activity