You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[RRFC] Exclude node_modules from Time Machine backups (macOS) #471
node_modules often contains a lot of files that change frequently, which can significantly slow down backup solutions like Time Machine, so it would make sense to exclude them from backups.
How
Current Behaviour
node_modules folders are included in Time Machine backups
Desired Behaviour
Exclude node_modules from Time Machine backups using a "sticky exclusion". This can be done by adding the xattr com.apple.metadata:com_apple_backup_excludeItem to the node_modules folders with the value com.apple.backupd encoded as a binary plist:
Reacted by Owen Buckley, Charlie Fish, adlawan, Dmytro Chyrkin, Callum Macdonald, Matt Pilott, Pascal Sthamer, Kagami, Alan Greene, Guillaume Khayat and 1 more
I spoke about this with a colleague and he said that he would be very surprised if it was the default behavior.
Maybe the proposal should be about an option that could be set in .npmrc
On the rfc call, we discussed some of the tradeoffs of an opt-in vs an opt-out; my take is that the risk caused by using opt-out is that your colleague would have to discover it, be unable to avoid needing internet after a restore, and then Google for the option, and then set it; the risk caused by it being opt-in is that someone’s backup disk prematurely fills up with node_modules and there’s no backup available to restore at all.
With opt-in, you might not realize that node_modules is clogging up and slowing down backups, and once you do you may assume there's no easy way around it.
With opt-out, you might not realize it's not backed up, and once you do you're likely to search for a solution if you want different behavior.
I think the vast majority of people would prefer node_modules to not be backed up, which would mean opt-out results in less issues/confusion. As far as I'm concerned, node_modules just acts as a cache based on package-lock.json, so I would not expect it to be in backups in the first place.
@isaacs's concern about shipping a binary addon is a big part of why an out-of-band tool is the pragmatic path while this is debated — the xattr can be set from userspace with no npm-shipped native code.
Sharing as prior art: I maintain tmtidy, which writes com_apple_backup_excludeItem directly (no tmutil, no sudo) on a launchd schedule. On @targos's restore-without-internet point — it's fully reversible (clear the xattr / removeexclusion), and because it's opt-out at the machine owner's discretion rather than baked into npm, nobody inherits the behavior unknowingly. That keeps the opt-in-vs-opt-out risk you discussed on the RFC call with the user, not the package. Might be a useful reference point for the design.
Activity
ljharb commentedon Oct 7, 2021
Ooh, this is interesting, i wonder if this would also exclude them from Dropbox syncing?
kasper9n commentedon Oct 7, 2021
@ljharb I don't think so. You can try run
tmutil addexclusion <path>to seeisaacs commentedon Oct 13, 2021
Does node provide a way to set xattrs? Shipping a binary addon in npm would be tricky.
ljharb commentedon Oct 13, 2021
Presumably the binary exists only on Macs, so you could shell out to it when present?
targos commentedon Oct 14, 2021
I spoke about this with a colleague and he said that he would be very surprised if it was the default behavior.
Maybe the proposal should be about an option that could be set in
.npmrcljharb commentedon Oct 14, 2021
@targos can you get some elaboration on why they’d want their node_modules to be backed up?
targos commentedon Oct 14, 2021
@ljharb They'd like their setup to work without an internet connection after restoring from a backup.
ljharb commentedon Oct 14, 2021
On the rfc call, we discussed some of the tradeoffs of an opt-in vs an opt-out; my take is that the risk caused by using opt-out is that your colleague would have to discover it, be unable to avoid needing internet after a restore, and then Google for the option, and then set it; the risk caused by it being opt-in is that someone’s backup disk prematurely fills up with node_modules and there’s no backup available to restore at all.
kasper9n commentedon Oct 14, 2021
With opt-in, you might not realize that
node_modulesis clogging up and slowing down backups, and once you do you may assume there's no easy way around it.With opt-out, you might not realize it's not backed up, and once you do you're likely to search for a solution if you want different behavior.
I think the vast majority of people would prefer
node_modulesto not be backed up, which would mean opt-out results in less issues/confusion. As far as I'm concerned,node_modulesjust acts as a cache based onpackage-lock.json, so I would not expect it to be in backups in the first place.adlawan commentedon Dec 1, 2021
Need the machine to rolling
chris-str-cst commentedon Aug 1, 2026
@isaacs's concern about shipping a binary addon is a big part of why an out-of-band tool is the pragmatic path while this is debated — the xattr can be set from userspace with no npm-shipped native code.
Sharing as prior art: I maintain tmtidy, which writes
com_apple_backup_excludeItemdirectly (notmutil, nosudo) on a launchd schedule. On @targos's restore-without-internet point — it's fully reversible (clear the xattr /removeexclusion), and because it's opt-out at the machine owner's discretion rather than baked into npm, nobody inherits the behavior unknowingly. That keeps the opt-in-vs-opt-out risk you discussed on the RFC call with the user, not the package. Might be a useful reference point for the design.