The Node.js fs module is your gateway to interacting with the file system. It provides synchronous and asynchronous methods to read, write, delete, and manipulate files and directories. At its core, it’s a thin wrapper around system calls, so performance closely follows the underlying OS capabilities.
One thing to grasp early is how the async and sync versions differ. The async methods accept callbacks or return promises, making them non-blocking. This very important for maintaining responsiveness in I/O-heavy applications. Conversely, sync methods block the event loop until completion – useful in scripts or initialization phases where simplicity trumps concurrency.
Let’s look at a basic example of reading a file asynchronously. Notice the signature: the last parameter is always a callback where the first argument is an error object if something went wrong.
const fs = require('fs');
fs.readFile('example.txt', 'utf8', function(err, data) {
if (err) {
console.error('Failed to read file:', err);
return;
}
console.log('File contents:', data);
});
Here, readFile handles both opening, reading, and closing the file behind the scenes. You don’t have to worry about file descriptors unless you want more granular control.
The fs module also supports Promises, which makes chaining and error handling cleaner, especially with async/await syntax.
const fs = require('fs').promises;
async function readExample() {
try {
const data = await fs.readFile('example.txt', 'utf8');
console.log('File contents:', data);
} catch (err) {
console.error('Failed to read file:', err);
}
}
readExample();
Behind that simplicity, the module exposes lower-level APIs like open, close, read, and write, which allow you to manage file descriptors manually. This is useful when you want to keep a file open for multiple reads or writes, reducing overhead. But for most use cases, the convenience methods like readFile and writeFile suffice.
Directories get their own set of functions. For example, fs.readdir reads the contents of a directory, returning an array of filenames or directory entries.
fs.readdir('./my-folder', (err, files) => {
if (err) {
console.error('Error reading directory:', err);
return;
}
console.log('Directory contents:', files);
});
One subtlety: paths in Node.js are relative to the process’s current working directory unless you specify absolute paths. This can trip you up if your script is run from different locations.
In sum, fs is a powerful yet simpler module that lets you treat your file system almost like an extension of your program’s memory, but with all the persistence and external constraints that implies. Next, we’ll see how to use it properly for deleting files while gracefully handling errors, which is where many beginners run into pitfalls.
Hastraith Stylus Pen for iPad(2018-2026)-13 Mins Fast Charge with Tilt Sensitivity & Palm Rejection for iPad 11/10/9/8/7/6th Gen, Air 5/4/3/M4/M3/M2, Pro 13"/12.9"/11"/M4, Mini 7/6/5th, White
$15.99 (as of June 3, 2026 23:09 GMT +00:00 - More infoProduct prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on [relevant Amazon Site(s), as applicable] at the time of purchase will apply to the purchase of this product.)Implementing file deletion with error handling
Deleting a file with the fs module is simpler, but error handling is essential to avoid crashes or silent failures. The basic asynchronous method is fs.unlink, which removes a file. If the file does not exist or the program lacks permissions, an error is passed to the callback.
const fs = require('fs');
fs.unlink('path/to/file.txt', (err) => {
if (err) {
console.error('Failed to delete file:', err);
return;
}
console.log('File deleted successfully');
});
That’s the foundation. However, in real-world applications, you often want to check if the file exists before attempting deletion or handle specific error codes differently. Using fs.stat or fs.access beforehand can help, but remember that checking before acting introduces a race condition – the file might be deleted by another process between your checks and the unlink call.
A more robust pattern is to attempt the deletion unconditionally and handle expected errors gracefully. For example, ignoring the error if the file was already missing, but reporting other errors:
fs.unlink('path/to/file.txt', (err) => {
if (err) {
if (err.code === 'ENOENT') {
// File doesn't exist, no need to delete
console.log('File already deleted.');
} else {
console.error('Failed to delete file:', err);
}
return;
}
console.log('File deleted successfully');
});
Using Promises and async/await, the same logic becomes cleaner and easier to follow. Here’s how you can implement file deletion with proper error handling in an async function:
const fs = require('fs').promises;
async function deleteFile(filePath) {
try {
await fs.unlink(filePath);
console.log('File deleted successfully');
} catch (err) {
if (err.code === 'ENOENT') {
console.log('File already deleted or does not exist');
} else {
console.error('Failed to delete file:', err);
}
}
}
deleteFile('path/to/file.txt');
Sometimes, you might want to delete multiple files in sequence or parallel, handling errors individually or collectively. Here’s an example deleting multiple files in parallel, collecting results:
async function deleteFiles(filePaths) {
const results = await Promise.allSettled(
filePaths.map(async (file) => {
try {
await fs.unlink(file);
return { file, status: 'deleted' };
} catch (err) {
if (err.code === 'ENOENT') {
return { file, status: 'not found' };
}
return { file, status: 'error', error: err };
}
})
);
results.forEach(result => {
if (result.status === 'fulfilled') {
const { file, status, error } = result.value;
if (status === 'deleted') {
console.log(${file}: deleted);
} else if (status === 'not found') {
console.log(${file}: file not found);
} else if (status === 'error') {
console.error(${file}: deletion error, error);
}
} else {
console.error('Unexpected rejection:', result.reason);
}
});
}
deleteFiles(['file1.txt', 'file2.txt', 'file3.txt']);
When deleting files, remember that permissions and locks can cause errors. On Windows, for instance, trying to delete a file that is open in another program might fail with an EPERM error. Handling such platform-specific errors may require retries, delays, or user notifications.
In short, always anticipate failure modes when deleting files. The best approach is to attempt the operation and handle errors explicitly, distinguishing between “file not found” and other failure reasons. This pattern keeps your code robust and predictable in the wild.
