Somehow support checking if a path exists while using fs.promises

[bnb]

Is your feature request related to a problem? Please describe.

Presently, fs.exists is deprecated and fs.existsSync is only available if you're not using promises. The exists check is absolutely useful, and it would be really useful to have it available in the fs.promises API.

Describe the solution you'd like

fs.promises,exists or fs.promises.existsSync should work.

Describe alternatives you've considered

• Status Quo: this leaves a weird and very unfortunate gap in our API.

[devsnek]

async function exists(f) {
  try {
    await fs.promises.stat(f);
    return true;
  } catch {
    return false;
  }
}

😄

[aduh95]

Alternatively, you can use fs.promises.access which is not exactly the same thing, but may fit your use case.

[targos]

I think it makes sense to implement fsPromises.exists. fs.exists is only deprecated because of its non-conventional callback signature.

[tniessen]

fs.exists is only deprecated because of its non-conventional callback signature.

Historically, that might be true, but exists is problematic for another reason. It often incorrectly returns false. The name is misleading at best.

> fs.existsSync('/root/snap') // existing directory but no permission
false

If we really want to keep using a misleading name, the documentation should be very clear that exists === false does not mean that the file does not exist.

[targos]

Instead of keeping the misleading name, I'd prefer we implement the promise version correctly: return a boolean if we know for sure whether the file exists or not, throw in other cases.

[tniessen]

I'd prefer we implement the promise version correctly: return a boolean if we know for sure whether the file exists or not, throw in other cases.

I tend to agree, but that's inconsistent with the existing APIs. And I have a feeling that most use cases won't handle that third case (throw) correctly. Personally, I believe that the semantics of access are not much more complicated than correctly using exists.

[targos]

Personally, I believe that the semantics of access are not much more complicated than correctly using exists.

I'm not sure I understand. Is your opinion that people should use fsPromises.access and that we shouldn't implement fsPromises.exists or that we should implement like the sync version?
The problem with access is that to use it inline (if (exists(somefile)) { ... }), you have to create a helper function to wrap the try/catch.

[tniessen]

I don't have a clear preference. The sync version makes a very weak statement: whether some file system entry is visible to the process right now. It doesn't make any statement about the type of the file system entry nor about permissions nor about the entry's existence during the processes' next CPU cycle.

I have a suspicion that the mere existence of exists promotes bad access patterns, such as race conditions (e.g., exists before open or readdir), or checking for existence when the process should really be using access to check for read permissions (e.g., directories), or checking if something exists when the process should really be using stat to check if it exists and is a regular file atomically.

However, there are surely some valid use cases that truly only care about the existence right now and about nothing else.

I don't have a strong opinion. Either throw, which is inconsistent with the other exists implementations and might not be what users expect, or swallow errors, which is misleading/incorrect and requires a big warning in the docs.

access and stat can be used instead of either option and only require one or two lines of code.

[jasnell]

The key challenge with exists in the promise API is that it, in absolutely no way, can tell you about the existence of the file right now. The best it can ever do is tell you that the file did exist at one point. If someone really does need to know only about the existence of a file right now the sync API remain the best option.