fix: use graceful-fs to retry transient EPERM/EACCES/EBUSY on Windows rename

[manzoorwanijk]

Summary

On Windows, fs.rename fails with EPERM: operation not permitted when another process (Windows Defender, Windows Search indexer, or a concurrent Node.js worker) holds a transient lock on the target file. This is especially prominent with npm's install-strategy=linked, where many files are written in parallel under a single .store/ directory, increasing the window for antivirus lock conflicts.

The root cause is that write-file-atomic uses bare require('fs'), which has no retry logic. graceful-fs already patches fs.rename on Windows with exponential backoff (up to 60s) for EACCES/EPERM/EBUSY errors (polyfills.js#L96-L120).

This PR switches from require('fs') to require('graceful-fs') to get that retry behavior.

Background

graceful-fs was originally a dependency of write-file-atomic but was removed in v3.0.0 to break a circular dependency that interfered with graceful-fs's own test suite (isaacs/node-graceful-fs#163). That circular dependency no longer exists since tap no longer depends on write-file-atomic.

Changes

• lib/index.js: Changed require('fs') to require('graceful-fs')
• package.json: Added graceful-fs (^4.2.11) as a dependency
• test/basic.js, test/concurrency.js, test/integration.js: Updated t.mock() calls to mock 'graceful-fs' instead of 'fs'

Related issues

• EPERM error on Windows when multiple processes try to write the same file #28 -- original report from 2017 (via Jest parallel workers)
• npm/cli#9021 -- npm CLI issue for linked strategy EPERM failures
• npm/cli#8072 -- EPERM during npm install on Windows with npm 10.x

References

Fixes #227, #28