Speed Up pnpm/npm/yarn Caches with ReFS Dev Drive

Developers on Windows often waste minutes per day waiting on dependency installs, Git status, and incremental builds. Windows 11 introduced Dev Drive, a developer-focused storage volume powered by ReFS and paired with Microsoft Defender’s Performance mode, to reduce file I/O overhead on common developer workloads. If you use Node.js package managers like pnpm, npm, or yarn, this guide shows you how to put the right caches on a Dev Drive to speed up installs and rebuilds—safely and repeatably.

You’ll learn exactly what Dev Drive and ReFS are, how Defender Performance Mode reduces antivirus overhead, which Node caches benefit the most, and where pnpm’s hard-linking model requires special care. We’ll provide practical step-by-step instructions, verification commands, and benchmarks you can reproduce in your environment.

H2 Overview: What Dev Drive, ReFS, and Defender Performance Mode do for Node package managers

• What is Dev Drive? A dedicated developer storage volume in Windows 11 that uses the ReFS file system and integrates with Microsoft Defender’s Performance Mode. It’s designed to improve I/O for developer workloads (source trees, package caches, build outputs) without sacrificing protection.
• What is ReFS? The Resilient File System. Compared to NTFS, ReFS focuses on integrity and scalability. It’s efficient with lots of small file churn typical in node_modules, caches, and build artifacts. Dev Drive uses ReFS by default.
• What is Defender Performance Mode? When Microsoft Defender Antivirus is the primary AV, Dev Drive volumes enable Performance Mode—a scanning strategy optimized for developer workloads that reduces the overhead of real-time protection on high-churn folders.

Where it helps most:

• Node.js workflows: faster npm/yarn cache hits, quicker extraction of tarballs, less overhead scanning node_modules and cache directories.
• Git operations: faster git status/log on large repos, especially with fsmonitor.
• Build tools: quicker cold/near-cold builds for tools like Next.js, Vite, TurboRepo, Webpack, esbuild, and Unreal/Unity asset caching.
• CI-like local workflows: frequent clean installs (npm ci), restore caches between branches, or testing multiple Node versions with nvm-windows.

Important nuance for pnpm users:

• pnpm’s big performance win comes from creating hard links from a content-addressable store into node_modules.
• ReFS currently does not support hard links. That means:
  • If your project and pnpm store live on ReFS, pnpm cannot use hard links and may fall back to copying, reducing pnpm’s advantage.
  • For pnpm, you’ll usually want to keep both your project and the pnpm store on NTFS (same volume), and use Dev Drive for other caches (npm, yarn, build caches, temp).
• npm and yarn benefit significantly from Dev Drive without the hard link constraint.

H2 Quick Reference: Commands and settings you’ll use

Command	Purpose	Example Output
winver	Check Windows version/build	Version 23H2 (OS Build 22631.XXX)
Get-Volume	List volumes and file systems	FileSystem: ReFS; DriveLetter: X
fsutil fsinfo volumeinfo X:	Verify ReFS on Dev Drive	File System Name : ReFS
New-DevDriveVolume -DriveLetter X -Size 200GB -Label DevDrive	Create a Dev Drive (PowerShell)	Creates X: labeled DevDrive (ReFS)
Set-FileIntegrity -FileName X:\caches -Enable $false	Disable ReFS integrity streams for a directory	File integrity disabled for X:\caches
Get-MpComputerStatus	Confirm Defender is active	RealTimeProtectionEnabled: True
npm config set cache X:\npm-cache –global	Move npm cache to Dev Drive	Sets cache to X:\npm-cache
yarn config set cache-folder X:\yarn-cache	Move yarn cache to Dev Drive	success Set “cache-folder” to “X:\yarn-cache”
pnpm config set store-dir D:.pnpm-store	Place pnpm store (NTFS)	scope: global; set store-dir=D:.pnpm-store
git config –global core.fsmonitor true	Enable Git built-in FSMonitor	(no output; speeds up status on large repos)
Measure-Command { npm ci }	Rough benchmark of install time	TotalMilliseconds: 32456

H2 Setup and Key Concepts

H3 Prerequisites and support

• Windows: Windows 11 22H2+ (Dev Drive debuted in 22H2 “Moment” updates; Windows 11 23H2 or later is recommended).
• Admin rights: You need admin rights to create/format volumes and to run some PowerShell commands.
• Antivirus: Microsoft Defender Antivirus should be the primary real-time protection product to get Performance Mode on Dev Drive. If a third-party AV is active, Performance Mode won’t engage.
• Disk space: Allocate a dedicated partition or VHD (fixed or dynamically expanding). 50–200 GB is typical, depending on the size of caches and repos you plan to place there.
• Developer Mode: For best Node tooling compatibility (symlinks, Junctions), enable Developer Mode in Settings.

H3 Check your Windows version and Defender status

• Windows version:
  • Run: winver
• Defender status (PowerShell, as admin):
  • Get-MpComputerStatus | Select RealTimeProtectionEnabled, AMServiceEnabled

H3 ReFS and Dev Drive basics you should know

• ReFS vs NTFS features:
  • ReFS: great for large directories and high-churn files; supports integrity streams.
  • ReFS currently does not support hard links. This is the crucial constraint for pnpm’s hard-linking strategy.
• Integrity streams:
  • ReFS can store checksums per file. For ephemeral cache folders, you can disable integrity streams to reduce overhead.
• Defender Performance Mode:
  • Automatically applies to Dev Drive volumes when Microsoft Defender is the active AV with real-time protection on.
  • It reduces the cost of scanning in high-churn developer workflows while maintaining security.

H3 When to use NTFS instead

• If your workflow depends on NTFS features not present in ReFS (notably hard links used by pnpm), keep the workspace and pnpm store on NTFS (same volume). You can still use Dev Drive for npm/yarn caches, temp folders, build caches, and downloaded artifacts.

H2 Step-by-Step Guide

H3 1) Create a Dev Drive (UI or PowerShell)

Option A: Create via Settings (no code)

• Settings -> System -> Storage -> Advanced storage settings -> Disks & volumes -> Create Dev Drive.
• Choose partition or virtual hard disk (VHD), size, and drive letter (for example, X:). The wizard formats it as ReFS and registers it as a Dev Drive.

Option B: Create via PowerShell (admin)

• If your disk has free space you can allocate:
  1. Create the volume:
     • New-DevDriveVolume -DriveLetter X -Size 200GB -Label DevDrive
  2. If the cmdlet isn’t available, create a ReFS volume manually:
     • Use Disk Management or PowerShell to create a partition
     • Format-Volume -DriveLetter X -FileSystem ReFS -NewFileSystemLabel DevDrive
     • Note: When created this way, it may not register as an official “Dev Drive,” but you still get ReFS benefits. Defender Performance Mode is tied to Dev Drive designation; prefer the Settings or New-DevDriveVolume method when possible.

Option C: Create a Dev Drive VHD (portable)

• New-VHD -Path “C:\Dev\DevDrive.vhdx” -SizeBytes 200GB -Dynamic
• Mount-VHD -Path “C:\Dev\DevDrive.vhdx” -PassThru | Initialize-Disk -PartitionStyle GPT -PassThru | New-Partition -DriveLetter X -UseMaximumSize | Format-Volume -FileSystem ReFS -NewFileSystemLabel DevDrive
• On newer builds, you can then designate it as a Dev Drive via Settings.

H3 2) Verify ReFS and Defender Performance Mode

• Verify file system:
  • fsutil fsinfo volumeinfo X:
  • Expected snippet: File System Name : ReFS
• Verify the volume is recognized as Dev Drive (UI):
  • Settings -> System -> Storage -> Disks & volumes -> select X: -> it should indicate Dev Drive.
• Verify Defender is active (PowerShell):
  • Get-MpComputerStatus | Select RealTimeProtectionEnabled
• Optional: Check Windows Defender Operational logs for Dev Drive performance events:
  • Event Viewer -> Applications and Services Logs -> Microsoft -> Windows -> Windows Defender -> Operational
  • Look for entries that indicate Dev Drive performance optimizations on volume X:.

H3 3) Plan your folder layout

• Recommended root folders on X:\ (Dev Drive):
  • X:\npm-cache
  • X:\yarn-cache
  • X:\build-cache (Vite, TurboRepo, Babel, Webpack)
  • X:\temp (user TEMP/TMP during builds)
  • X:\artifacts (output zips, bundles, logs)
• Avoid putting pnpm projects on ReFS if you rely on pnpm’s hard links. Keep those projects and the pnpm store on the same NTFS volume. You can still benefit by putting other caches on Dev Drive.

H3 4) Move package manager caches

npm (global cache)

• Command:
  • npm config set cache X:\npm-cache –global
• Confirm:
  • npm config get cache
• Optional: move per-project cache (if using local .npmrc) by running the same command without –global in the project directory.

yarn (Classic and Berry)

• Command:
  • yarn config set cache-folder X:\yarn-cache
• Confirm:
  • yarn config get cache-folder

pnpm (store directory)

• Important: pnpm’s store should live on the same volume and file system as your projects to preserve hard linking.
• If your projects are on NTFS D:, set:
  • pnpm config set store-dir D:.pnpm-store
• If you put the store on the Dev Drive (ReFS), pnpm can’t hard link; installs may fall back to copying and be slower. Only do this if you accept the trade-off.

H3 5) Put TEMP/TMP on Dev Drive during builds (optional)

• Builds (node-gyp, compilers) use TEMP/TMP heavily.
• Create X:\temp.
• Edit Environment Variables (User scope is safest):
  • TEMP = X:\temp
  • TMP = X:\temp
• Restart shells/IDEs. Verify:
  • echo %TEMP% (cmd)
  • $env:TEMP (PowerShell)
• Note: Some legacy installers assume TEMP on the system drive—if you see odd installer errors, temporarily revert.

H3 6) Disable ReFS integrity streams on ephemeral caches (optional but recommended)

• For high-churn cache folders on ReFS, disable integrity streams to reduce overhead:
  • Set-FileIntegrity -FileName X:\npm-cache -Enable $false
  • Set-FileIntegrity -FileName X:\yarn-cache -Enable $false
  • Set-FileIntegrity -FileName X:\build-cache -Enable $false
• Do NOT disable integrity on source code folders or important artifacts you care to protect.

H3 7) Optional: Defender exclusions (use sparingly)

• Performance Mode already optimizes scanning on Dev Drive. Adding exclusions reduces protection and is generally not necessary.
• If you must exclude a volatile build cache as a last resort:
  • Add-MpPreference -ExclusionPath “X:\build-cache”
• Avoid excluding node.exe, powershell.exe, or entire drives.

H3 8) Speed up Git on large repos

• Enable built-in fsmonitor (Git 2.37+):
  • git config –global core.fsmonitor true
• Enable untracked cache (helps status on big repos):
  • git config –global core.untrackedCache true
• For Windows path lengths:
  • git config –global core.longpaths true
  • reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f
• Keep repos and working directories on Dev Drive if they don’t require NTFS-only features you’re using. Otherwise, keep repo on NTFS and use Dev Drive for caches.

H3 9) Benchmark your gains

Example 1: npm cold vs warm install

• Clear cache:
  • rmdir /s /q X:\npm-cache
  • npm cache clean –force
• Cold install:
  • Measure-Command { npm ci }
  • Example result: 52,340 ms
• Warm install (cache present):
  • Measure-Command { npm ci }
  • Example result: 31,780 ms

Example 2: yarn classic cold vs warm

• Clear cache:
  • rmdir /s /q X:\yarn-cache
• Cold install:
  • Measure-Command { yarn install –frozen-lockfile }
  • Example result: 49,600 ms
• Warm install:
  • Measure-Command { yarn install –frozen-lockfile }
  • Example result: 28,900 ms

Notes:

• Expect speedups from:
  • Cache hits on a fast, low-overhead volume (Dev Drive/ReFS).
  • Reduced antivirus overhead via Performance Mode.
• Numbers vary by hardware, repo, network, and lockfile consistency.

H2 Troubleshooting

H3 Can’t find “Create Dev Drive” in Settings

• Cause: Windows build too old or SKU doesn’t include Dev Drive UI; or corporate policy disabled it.
• Fix:
  • Update to Windows 11 23H2+ if possible.
  • Try PowerShell: New-DevDriveVolume (if available).
  • As a fallback, format a volume as ReFS (Format-Volume) and use it for caches; note that without the Dev Drive designation, Defender Performance Mode won’t apply.

H3 New-DevDriveVolume command not recognized

• Cause: Older PowerShell/Windows build.
• Fix:
  • Update Windows.
  • Use Settings UI to create a Dev Drive.
  • Or manually create a ReFS volume with Format-Volume, then consider converting it to a Dev Drive via UI when available.

H3 Defender Performance Mode not active on Dev Drive

• Cause: Third-party antivirus is the primary AV; Defender is passive; or real-time protection is off.
• Fix:
  • Make Microsoft Defender the primary AV and turn on real-time protection.
  • Verify: Get-MpComputerStatus | Select RealTimeProtectionEnabled
  • Reboot and check Windows Security -> Virus & threat protection settings.

H3 pnpm installs are slower on Dev Drive

• Cause: ReFS does not support hard links; pnpm can’t hard-link from store to node_modules.
• Fix:
  • Keep pnpm store and projects on the same NTFS volume (e.g., D:) to preserve hard links:
    • pnpm config set store-dir D:.pnpm-store
  • Use Dev Drive for npm/yarn caches and build caches only.

H3 git status is slow on large repos

• Cause: Large untracked sets; high I/O scans.
• Fix:
  • git config –global core.fsmonitor true
  • git config –global core.untrackedCache true
  • Place the repo on Dev Drive if it doesn’t require NTFS-only features you rely on.

H3 “EPERM: operation not permitted, symlink” during yarn/pnpm

• Cause: Symlink creation requires Developer Mode or admin privileges.
• Fix:
  • Enable Developer Mode: Settings -> Privacy & security -> For developers -> Developer Mode.
  • Or run the shell as Administrator.

H3 Path-too-long errors in node_modules

• Fix:
  • Enable long paths:
    • reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_DWORD /d 1 /f
  • git config –global core.longpaths true
  • Reopen shells/IDEs.

H3 “Access denied” toggling integrity streams

• Cause: Elevated privilege required.
• Fix:
  • Run PowerShell as Administrator.
  • Ensure no processes hold locks on the target directories when toggling integrity.

H2 Performance Tips & Best Practices

H3 Choose the right volume for the right workload

• Use the Dev Drive (ReFS) for:
  • npm and yarn caches
  • Build caches (Vite, TurboRepo, Webpack, Babel, Next.js .next/cache, etc.)
  • Temporary directories (TEMP/TMP) during builds
  • Downloaded artifacts (archives, toolchains you unpack frequently)
• Keep on NTFS:
  • pnpm projects and pnpm store (to preserve hard-link performance)
  • Any tools that explicitly require NTFS-only features

H3 Keep caches together and short paths

• Use top-level directories like X:\npm-cache, X:\yarn-cache, X:\build-cache for faster traversal and fewer path length issues.

H3 Consider disabling ReFS integrity on high-churn caches

• Use Set-FileIntegrity -FileName -Enable $false on Dev Drive cache folders only.
• Do not disable integrity on source code or critical assets.

H3 Avoid unnecessary antivirus exclusions

• Let Defender Performance Mode do the heavy lifting. Add exclusions only when absolutely necessary, and scope them narrowly.

H3 Tune Windows Search indexing

• High-churn cache folders don’t need to be indexed:
  • Open “Indexing Options” -> Modify -> uncheck your Dev Drive cache directories.
• Reduces background indexing I/O.

H3 Keep enough free space and monitor health

• Maintain 15–20% free space on the Dev Drive for sustained performance.
• Use Optimize-Volume for scheduled maintenance where applicable:
  • Optimize-Volume -DriveLetter X -Analyze
  • Optimize-Volume -DriveLetter X -Defrag (ReFS may skip defrag; Windows will choose appropriate optimization)

H3 Stable Node toolchains

• Use the same Node version across installs to maximize cache reuse (e.g., nvs or nvm-windows).
• Prefer lockfile-driven installs (npm ci, yarn install –frozen-lockfile) for repeatability.

H3 Benchmark method you can trust

• Use Measure-Command in PowerShell to compare wall-clock time.
• Run each scenario multiple times; take the median.
• Clear caches explicitly before cold runs; reuse caches for warm runs.
• Record:
  • OS build, Node.js version, npm/yarn/pnpm version
  • Drive type (SSD/NVMe), Dev Drive or NTFS
  • Antivirus status (Defender Performance Mode on/off)

H3 When not to use Dev Drive

• If your workflow is pnpm-centric and you need hard links for peak performance, moving the entire workspace to Dev Drive (ReFS) is counterproductive. Keep such projects on NTFS and use Dev Drive only for compatible caches.

H2 Conclusion

By placing the right caches on a Dev Drive and letting ReFS plus Defender Performance Mode reduce scanning overhead, you can meaningfully speed up npm and yarn installs, Git operations, and build steps. The key is choosing the right layout: use Dev Drive for npm/yarn caches, build caches, temp files, and artifacts, while keeping pnpm projects and store on NTFS to preserve hard-link performance.

These changes are safe, reversible, and easy to verify with the commands provided. Once set up, you’ll spend less time waiting on I/O and more time shipping code.

H2 FAQ

H4 Does Dev Drive work on Windows 11 Home?
Dev Drive is officially available on supported Windows 11 editions (Pro, Enterprise, Education). Availability on Home may be limited or absent, and some UI or PowerShell features might not appear. If you don’t see “Create Dev Drive,” update Windows or use a ReFS volume as a partial fallback (without Defender Performance Mode).

H4 Can I put my entire project repo on Dev Drive?
Yes, if your tools don’t need NTFS-only features. For most npm/yarn workflows, it works well. For pnpm, avoid ReFS for the workspace and store because pnpm relies on hard links; keep those on the same NTFS volume.

H4 Is it safe to disable integrity streams on ReFS?
Yes for ephemeral, high-churn caches (npm/yarn caches, build caches). Do not disable integrity on important data (source code, critical artifacts). Disabling integrity reduces overhead at the cost of ReFS checksum protection on those files.

H4 Do I need to add Defender exclusions for performance?
Usually no. Defender Performance Mode on Dev Drive significantly reduces scanning overhead. Add exclusions only if you’ve profiled a specific path as a bottleneck and you accept the risk; scope narrowly.

H4 Can I use a VHD-based Dev Drive?
Yes. VHD/VHDX Dev Drives are supported and are great for portability and quick cleanup. Create and mount the VHDX, format as ReFS, and designate it as a Dev Drive via Settings. Performance is typically good on NVMe SSDs; keep the VHDX on fast storage.