Repository navigation
test_runner: support mock file system #55902
Description
What is the problem this feature will solve?
The current test requires writing files to a real disk when reading and writing files related to the file system, which is very unsafe.
After all, the file may remain due to test case failure and other reasons.
What is the feature you are proposing to solve the problem?
Under the mock namespace, APIs are exposed to provide a mock file system.
mock.fileSystem.enable({ });And provide some options
e.g.
Override the file that defined by defaults
mock.fileSystem.enable({
files: {
'/path/to/file': new Uint8Array([0])
}
});
// it will read the virtual file system first if it does exist
// if not found, then read the read the real file system
fs.readFileSync('/path/to/file')Override the whole file system
mock.fileSystem.enable({
files: {
'/path/to/file': new Uint8Array([0])
},
override: true // override the whole file system
});
// This file is exists in the real file system
// But not define in the vitual file system, so it should throw an error
fs.readFileSync('/etc/proc')
Activity
cjihrig commentedon Mar 5, 2025
It seems unlikely that anyone will pick this up since it has been open for nearly 5 months with no interactions. I think this would be a neat feature, but I'm not sure if it belongs in core (or if it does, it may be a better fit for
fsthan the test runner).github-actions commentedon Sep 2, 2025
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-staleIssues and PRs exempt from automated stale handling.
label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
axetroy commentedon Sep 2, 2025
bump
sozua commentedon Jan 10, 2026
Bringing back this discussion, @cjihrig. I'd like to try helping on this, but wanted to clarify some things first.
1: On whether this belongs in the test runner or
fs: the test runner already ownsmock.timersand module mocking. Wouldmock.fsfit that pattern, or is there a reason to keep it closer to thefssubsystem?2: The
fsAPI surface is large, so full coverage isn't very practical for a first pass. A starting point could be basic file I/O and directory operations. Enough to let tests define virtual files and avoid writing to disk. Unmocked paths could fall back to real fs, or throw if the user wants full isolation.Does that seem like a reasonable scope, or should the first iteration be narrower/broader?
cjihrig commentedon Jan 10, 2026
@sozua I'm going to ping @nodejs/test_runner about your comment above ^. I personally don't have an opinion on it.
MoLow commentedon Jan 15, 2026
Id add it as mock.fs, and mark it as experimental, to allow it to be gradually implemented
ljharb commentedon Jan 15, 2026
I would suggest keeping it behind a flag - not just marked as experimental (which is largely useless, because if it gets sufficient adoption it can't be removed anyways) - until it has full API coverage.
github-actions commentedon Jul 20, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
axetroy commentedon Jul 20, 2026
bump
pmarchini commentedon Jul 20, 2026
We might want to take a look at #63115 👀
axetroy commentedon Jul 20, 2026
This is a virtual file system, and it doesn't seem to be able to meet this requirement.
Because our actual code will definitely use
node:fsto operate on files.It wouldn't make sense to modify the source code to replace the
node:fsmodule withnode:vfsjust for the sake of testing.pmarchini commentedon Jul 20, 2026
No I agree, what I'm saying is that we can use vfs as a base for the fs mock system!