Tools: Why Deleting `node_modules` Takes Forever on Windows
The Real Reason Isn’t Just “Too Many Files”
1. Windows Deletes Files One by One
2. File Locking Adds Extra Overhead
3. Windows Defender Is the Biggest Bottleneck
4. Long File Paths Make Things Worse
5. NTFS File System Overhead
How Linux and macOS Handle It Differently
Quick Comparison
Why Windows Prioritizes Safety
Can You Speed It Up?
Final Thoughts A few days ago, I was deleting a project when something unexpectedly frustrating happened — it took way too long. Not seconds. Not even a minute. It just kept going. If you’ve worked with JavaScript projects, you already know the culprit: node_modules. That moment got me thinking. Since I’ve been studying operating system fundamentals, I wanted to understand what’s actually happening behind the scenes. Why does a simple delete operation take so long? So I went down the rabbit hole — digging through documentation, GitHub discussions, and system-level explanations. I even explored how Linux handles file deletion to compare behaviors. Yes, node_modules contains thousands of files — sometimes hundreds of thousands. But that’s only part of the story. The real reason deletion is slow on Windows comes down to how the operating system handles: Unlike what many people assume, Windows does not delete folders in bulk. Now imagine doing that for 100,000+ files. That alone creates noticeable delay. Windows uses a strict file locking mechanism. Before deleting a file, it: If anything is being accessed — even indirectly — the system slows down or retries the operation. This adds friction, especially in deeply nested folders like node_modules. This is where most of the time actually goes. Windows Defender scans files not just when they’re created or opened — but also when they’re deleted. That might sound unnecessary, but there’s a reason. To prevent this, Windows scans files during deletion as well. In many cases, 60–70% of the total deletion time is spent on Defender scans alone. node_modules often contains deeply nested dependencies. This leads to extremely long file paths. Windows has historically had a path length limit (~260 characters). Even though modern systems support longer paths, many tools still struggle with them. When paths exceed limits: Windows uses the NTFS file system, which prioritizes reliability and consistency. For every file deletion, NTFS: Doing this for thousands of files significantly slows things down. Unix-based systems take a much simpler and faster approach. The result is a noticeable difference in performance. At this point, it’s fair to ask: why does Windows do all this? The answer is simple — security. Without these checks: So while it feels inefficient, it’s a deliberate design decision. Yes — but every shortcut comes with trade-offs. Some practical options: You can also disable real-time antivirus scanning temporarily, but that introduces risk and isn’t advisable for regular use. Deleting node_modules slowly on Windows isn’t a bug — it’s the result of intentional system design. Windows favors safety and control.
Unix-based systems favor speed and simplicity. Once you understand that trade-off, the behavior makes a lot more sense — even if it’s still frustrating. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - File system operations- Security checks- Path resolution- File locking - Traverses every directory- Deletes each file individually- Updates metadata for every operation - Checks whether the file is in use- Verifies parent directories- Temporarily locks parts of the directory structure - Create harmful files- Execute them- Delete them quickly to avoid detection - Operations can fail- Windows retries them silently- Additional time is wasted - Updates logs- Maintains metadata- Ensures file system integrity - Avoid heavy antivirus scanning during deletion- Use more efficient file unlinking mechanisms- Have fewer restrictions on file paths- Use a more flexible file locking model - Malware could create and delete files instantly- Those files might never be scanned- The system could be compromised silently - Use tools like rimraf for faster deletion- Enable long path support in Windows- Use WSL (Windows Subsystem for Linux) for development workflows- Avoid reinstalling dependencies unnecessarily