Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (b523ae4) 99.78% compared to head (0100ed9) 99.78%.
Report is 3 commits behind head on master.

❗ Current head 0100ed9 differs from pull request most recent head 72007ec. Consider uploading reports for the commit 72007ec to get more accurate results

@@           Coverage Diff           @@
##           master    #5058   +/-   ##
=======================================
  Coverage   99.78%   99.78%           
=======================================
  Files         221      221           
  Lines       16345    16351    +6     
  Branches     3933     3936    +3     
=======================================
+ Hits        16310    16316    +6     
  Misses         35       35           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This package however is actually a re-export of the callback version of node:fs' writeFile.

Are you sure about that? The library itself is using it by awaiting internally:

https://github.com/jprichardson/node-fs-extra/blob/master/lib/ensure/file.js#L24

Also the types say it's the promisified version.

If it's true, it sounds like something worth reporting and fixing upstream.

FWIW, I don't think I saw a flaky test that would point to this problem, so could be surely windows specific.

I don't think this is true, when I console.log the method without awaiting, I get a Promise instance back.

import { writeFile } from 'fs-extra';

console.log(writeFile('foo', 'bar'));

Promise { <pending> }

Hm... after digging through more sources, it seems the "core" of this is in graceful-fs. fs-extra is re-exporting that, and wrapping it up with universalify to make it promise based.

So... yes, there is a promise there, but it seems there may be some kind of an edge case, at least on Windows, where the native promise writeFile handles things properly, while the universalify writeFile does not.

The graceful-fs package mentions in their readme

On Windows, it retries renaming a file for up to one second if EACCESS or EPERM error occurs, likely because antivirus software has locked the directory.

which leads me to believe that may be what's happening here, except I don't get those errors... It's just that pathExists sometimes returns false, even though it shouldn't. I'm guessing I would've gotten those exact errors if the test was trying to read the file, not just check for its existence.

Or, equally likely, the native promise version is scheduling the flushes differently, and so without an explicit flush option or filehandle.sync() call, the end result is that the flush is scheduled later with the non-natively promised version.

A more reliable fix would be to take advantage of the flush option in Node 21 I guess (see nodejs/node#50009 ), which would be ignored for versions that don't support it. I've now changed the PR to that. I re-ran the tests several times, and so far at least, I haven't gotten a single flaky test.