It also doesn't help that there's no way to exclude a folder with wildcards so you can't blacklist all node_modules folders.
Same way that Dropbox works
So they are not manually choosing what to sync, they just put all of the work and other files they want to automatically sync inside of that folder. This ends up including things like node modules and things like that
As for corruption or overwriting files, I have rarely encountered issues, but Drive has file revision histories as well as a Trash can, so if you notice the problem and it's not spread over 5M files, you can roll back to last-known-good versions.
Implementation-wise under the hood is it really much different?
In my simplistic, probably overly naive idea it seems that a “network drive” built on top of Google Drive would still cache the files in memory, and improper shutdown or loss of network access could still leave your files in an inconsistent state. Probably they have a lot of advanced logic on top, that could roll back partial updates, or keep track of things so that the updates are not applied before sync is complete.
But anyways from this point of view sync vs network mounted drive feels like sync is a kind of network mounted drive that flushes to local disk in addition to working with the remote.
One of these days I want to build such things from scratch myself so that I can experience first-hand the horrors that lie underneath sync / network disk service setups modelled on my idea of Dropbox / Google Drive etc
I’m on a Mac and find that google drive’s Mac client is so unreliable as to be useless. It frequently crashes mysteriously, and even when running it doesn’t sync reliably. It feels like nobody is working on the software, and after all the layoffs that could well be true.
Say what you want about Dropbox, but I’ve never had a problem with it.
True.
I used Dropbox for many years without issue and moved because of the cost and the issue a few years back with not allowing it on certain Linux file systems.
Went to Google Drive and performance was shocking in comparison. At the time (don't know about now) it also felt like they had a deliberate policy to avoid showing cumulative file/folder sizes, meaning it was easier to pay for more storage than to find out what took the space and clean it up.
Since then I've spent a few years using PCloud, which was almost as fast as DropBox and more reliable at syncing than Google. Then I lost the ability to connect the client on a Mac for a couple of days, had a deeper look, and noticed a few files had had silent collisions between changes on Mac and Windows (not at the same time) leaving multiple versions (names suffixed with the machine they came from).
So I left there and went to OneDrive. To be honest I've found it okay other than one issue on a Mac where if I delete a file for some reason then when it vanishes to the recycle bin it reappears in the OneDrive root on the laptop. delete-immediately gets around that.
I'm now at the point where I use OneDrive for convenience/reliability but despite the cost have been considering a return to DropBox as cloud syncing seems to be impossible for anyone else to do properly. Is it still as reliable as it used to be?
But much better than google which just silently fails.
Now in your risk assessment the question of course is how likely it is that you lose the copy alone your dev system, CI system and productive version at the same time that npm loses it, but the first three happening isn't as unlikely as it seems: You work on a major refactoring and while deploying you run into a major problem and want to roll back, then artifacts from the old version might be gone. Of course there are ways to prevent that. But that's the risk assessment and prevention you have to make. A full backup including node_modules is one way of dealing with that.