Network's Themes' Node Module Bloat


(John Cory) #1

Hello.

I’m approaching gulp and grunt-based theme development on a WP network without much of a background in Node.js and wondering if I’m going about this poorly.

I have a particular WP network with at least 12 individually themed sites on it. (The client is a designer. All their sites look different.) I use Gulp and Grunt files to help me with SASS and things. Generally, I end up with 60mb+ of a /node_modules/ directory in each theme or child theme directory even though I think all of the themes would use the same structure and Gulp-or-Gruntfile.js … unless I’m forgetting an aspect of that. Offering both here as I don’t really care which one I use unless it matters.

I know 60mb might not amount to much for some, but I also like the idea of using a master gulpfile. Should I be sharing resources across all of these themes somehow? I do use .gitignore to make sure I’m not committing stuff like that, but it’s still seems repetitive to keep all of this stuff on my local machine.

Thanks
Cory

PS: Apologies if I’m forgetting a fundamental concept of Grunt or Gulp or Node. I haven’t set up a site in a couple of weeks and am writing this as I try to remember why I’m doing this the way I have in the past. There are also so many basic tutorials about grunt and gulp theme development, I’m having trouble zeroing in on an answer to this specific question. I also have to work on a Windows machine, fwiw.


#2

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. :slight_smile:


(John Cory) #3

Thanks, Maiki. I’m not developing on the live, production multisite. I’m developing locally and ignoring the node_modules as you mentioned.

I’m just asking if anyone keeps a single Gulp or Gruntfile and a single node_modules colletion for all of their local theme development. I keep a separate collection in every theme even though they all have the same modules, do the same things.


#4

I keep all of my projects separate. I tend to run light, though. It is generally advised against linking to packages like that, because changes to any of the projects could write the incorrect package version and break all the rest.

Of course it seems unlikely you would do that by yourself, so I guess it is a question of how doing that will affect your workflow when you are forced to not do that, such as in collaboration with someone online. I’d stick with segregated projects. :slight_smile: