You kinda describe a scenario that shouldn’t exist, but I am not sure if you are worried about the same thing I would. Anyhow, it sounds like you are developing a bunch of sites in a live, production multisite.
Do not develop software on a production server.
The way to develop in node is with version control, ignoring
node_modules (this direction won’t be in the repo), and just updating your automation and lock files. The reason for that is if a person needs to develop the same software, they run
node and Grunt from their local machine and all the software will install.
Depending on their system, they may already have the packages cached, but at any rate the
node_modules directory will be built for them, as needed. I mention this because if your client is changing anything in the tasks, this is how they do it.
As for deploying your theme changes to a site, there are a lot of ways to do this, but the point is that you only pull in changes to the production site; it isn’t the development environment. That could mean running a
git pull on the theme directory, or manually packaging the theme as WordPress requires (meaning no task or source files from task runners).
I personally suggest WP Pusher. I use it with GitLab webhooks, so when I update a theme or plugin and change the semantic version, the repo tells the WordPress site, which then updates the theme or plugin from the git repo (via WP Pusher).
I develop the actual themes locally, so it doesn’t really matter how big the
node_modules are (I say that, because 60MB seems reasonable, while 1GB seems too much, and I know they can get bonkers like that). For tips on developing locally, check out our conversation about cloning sites, I list some tools I use.
And in closing, here is how a theme/plugin change happens for my client:
- Request for change happens (I use self-hosted GitLab instance, where my clients have accounts and can ask for changes as an issue in the relevant repo. Otherwise they email me or chat at me, and I create the issue myself.).
- I make the change on my laptop, able to check the changes against a clone of my client’s site that I keep locally for changes (with VVV, and syncing the site up every few months).
- When the changes are done, I bump the version number appropriately, and
git tag $VERSION and push it all to the remote repo in GitLab.
- When GitLab sends the webhook, the WordPress site will download the latest version of the theme/plugin. It is now live!
This is the dope workflow, I encourage you to look into it.