Port File System APIs in Deno namespace to @std/fs

We aim to make @std/fs cross-runtime (ref #4313). To achieve that we need to port FS APIs from Deno namespace (with Node.js compatibility)

Deno FS APIs https://docs.deno.com/api/deno/file-system
deno-shim https://github.com/denoland/node_shims/tree/main/packages/shim-deno/src/deno/stable/functions

Classes

Functions

shim-deno package already implements Node.js compatible Deno APIs. We can borrow the code from there for the Node.js compatibility part https://github.com/denoland/node_shims/tree/main/packages/shim-deno

feat(fs/unstable): added DirEntry type and conversion function denola…

feat(fs/unstable): added readDir function and test denoland#6255

feat(fs/unstable): added import references for readDir denoland#6255

Are unlink and unlinkSync ignored?

It looks like Deno doesn't have unlink and unlinkSync. Instead it has remove and removeSync. This list tries to mirror Deno FS APIs.

Considering compatibility with Node, should fs.unlink and fs.unlinkSync also be provided?

Do you suggest unlink would be an alias to remove?

Yes, except for compatibility, link and unlink is a pair, which is make more sense and more understandable than remove. WDYT?

Looked at the docs again, (Deno's) remove has an option like recursive (it can remove the entire directory), but unlink (of Node) doesn't. I feel unlink can't replace remove, and it feels like a limited version of remove.

BTW Node.js also has rm which is similar to Deno's remove.

TLDR: As a general question, should there be stronger checking of arguments when using the new @std/fs APIs under a Node.js runtime?

For example, the symlink and symlinkSync APIs in Node.js accept string | URL | Buffer types for path and target parameters whereas for Deno, the same APIs would require string | URL types (no Buffer) for these parameters. To meet the design intent of @std/fs APIs satisfying Deno's version of this API, would it be sensible to require rejecting/throwing with TypeErrors when passing Buffer objects when using the @std/fs APIs under a Node.js runtime? TypeError Buffer checking would also affect other @std/fs APIs: rename[Sync], realPath[Sync], et al.

Similarly, the Node.js versions of readFile[Sync] and writeFile[Sync] accept string | URL | Buffer | FileHandle/number (number for file descriptors, fd) types for the path parameter. When compared with Deno, path is restricted to string | URL types. TypeErrors would similarly need to be implemented when attempting to pass Buffer and FileHandle/fd types in the @std/fs versions of read[Text]File[Sync] and write[Text]File[Sync] when running Node.js.

I can either share a proposed approach for error checking here or in a forthcoming PR, whichever you prefer. I'd also be curious to know what your thoughts are about adding TypeError checking for these APIs when running under Node.js.

Navigation Menu

Repository navigation

Port File System APIs in Deno namespace to `@std/fs` #6255

Classes

Functions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Port File System APIs in Deno namespace to @std/fs #6255

Description

Classes

Functions

Activity

eryue0220 commented on Feb 5, 2025

kt3k commented on Feb 5, 2025

eryue0220 commented on Feb 5, 2025

kt3k commented on Feb 6, 2025

eryue0220 commented on Feb 6, 2025

kt3k commented on Feb 6, 2025

jbronder commented on Feb 16, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Port File System APIs in Deno namespace to `@std/fs` #6255