re: The node_modules problem VIEW POST

re: I understand. But, I would not recommend you using Dropbox as source control, because you run into the problems as you just mentioned previously.

When using Azure DevOps, like in my case, adding a git repo can be as fast as creating a project and saving it to Dropbox.

PS: Dropbox gets full fast (not paying for it)!
PPS: Use a .gitignore file but I guess you knew that.

@mroggy85 :

"If your code is under source control what is the need for copy them for backup?"

"I think that's where your problem lies and then your article is about one of the symptoms when not using source control."

Not every project is meant to be on GitHub and a local repository won't fix the problem.

The problem is that you have to delete all the node_modules folders manually in a up to infinity number of project folders and then re-install them after moving.

Maybe you can do that with a little cli magic, but that's not really user friendly and will take it's time...

I understand that it can be a litte inconvenience that one time you move your project. But I would not call it a common use case moving project files around. Then, I would suggest that you review your development process instead.

There are lots of steps between github and a local repo. For example, for small one-off projects I'll start with a local repo and then clone it on my other dev machine (each repo is a remote for the other, so I can easily sync changes back and forth). As it gets bigger, it can be pushed to the gitolite install I have on my media PC (which was just a random machine I had lying around that was always on; a Raspberry Pi would do just as well). Only when I want other people to look at it do I push to Github.

Even if you're just using local repos, git still helps you out; you only need to back up the .git directory; to restore, you put it back in place and run git checkout HEAD. No backing up of node_modules necessary!

Code of Conduct Report abuse