Skip to content
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.

Sign up for GitHub

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

Jump to bottom

fs: remove experimental language from rmdir recursive #35171

Closed
wants to merge 1 commit into from
Closed

fs: remove experimental language from rmdir recursive #35171

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 18 additions & 4 deletions doc/api/fs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3522,8 +3522,6 @@ changes:
it will emit a deprecation warning with id DEP0013.
-->

> Stability: 1 - Recursive removal is experimental.

* `path` {string|Buffer|URL}
* `options` {Object}
* `maxRetries` {integer} If an `EBUSY`, `EMFILE`, `ENFILE`, `ENOTEMPTY`, or
Expand All @@ -3546,6 +3544,12 @@ to the completion callback.
Using `fs.rmdir()` on a file (not a directory) results in an `ENOENT` error on
Windows and an `ENOTDIR` error on POSIX.

Setting `recursive` to `true` results in behavior similar to the Unix command
`rm -rf`: an error will not be raised for paths that do not exist, and paths
that represent files will be deleted. The permissive behavior of the
`recursive` option is deprecated, `ENOTDIR` and `ENOENT` will be thrown in
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nodejs/tsc I thought it might be most elegant in v16 that we make rmdir/recursive either match the behavior of .NET, Python, or Deno, with folks using rm if the want looser (rather than introducing yet another method). Which is how I landed on this language...

I figure we have some time to get this perfect, with it being most important for Node@v15 that we:

  • try to land a new method rm.
  • get the deprecation in place for folks using the existing approach.

the future.

## `fs.rmdirSync(path[, options])`
<!-- YAML
added: v0.1.21
Expand All @@ -3569,8 +3573,6 @@ changes:
`file:` protocol. Support is currently still *experimental*.
-->

> Stability: 1 - Recursive removal is experimental.

* `path` {string|Buffer|URL}
* `options` {Object}
* `maxRetries` {integer} If an `EBUSY`, `EMFILE`, `ENFILE`, `ENOTEMPTY`, or
Expand All @@ -3590,6 +3592,12 @@ Synchronous rmdir(2). Returns `undefined`.
Using `fs.rmdirSync()` on a file (not a directory) results in an `ENOENT` error
on Windows and an `ENOTDIR` error on POSIX.

Setting `recursive` to `true` results in behavior similar to the Unix command
`rm -rf`: an error will not be raised for paths that do not exist, and paths
that represent files will be deleted. The permissive behavior of the
`recursive` option is deprecated, `ENOTDIR` and `ENOENT` will be thrown in
the future.

## `fs.stat(path[, options], callback)`
<!-- YAML
added: v0.0.2
Expand Down Expand Up @@ -5475,6 +5483,12 @@ Using `fsPromises.rmdir()` on a file (not a directory) results in the
`Promise` being rejected with an `ENOENT` error on Windows and an `ENOTDIR`
error on POSIX.

Setting `recursive` to `true` results in behavior similar to the Unix command
`rm -rf`: an error will not be raised for paths that do not exist, and paths
that represent files will be deleted. The permissive behavior of the
`recursive` option is deprecated, `ENOTDIR` and `ENOENT` will be thrown in
the future.

### `fsPromises.stat(path[, options])`
<!-- YAML
added: v10.0.0
Expand Down