How are you handling node_modules for polecats?

[aleiby]

I kept running out of memory with several polecats working in parallel. A large aspect of this was executing npm ci in each polecat git worktree simultaneously. I added a setup hook:

  #!/bin/bash
  # Ensure node_modules is available for polecat worktrees.
  # Uses flock to serialize npm ci across concurrent polecat spawns.
  # Only runs npm ci if package-lock.json changed since last install.

  SOURCE="$GT_RIG_PATH/mayor/rig"
  LOCKFILE="$GT_RIG_PATH/.runtime/npm-install.lock"
  HASHFILE="$GT_RIG_PATH/.runtime/npm-install.hash"

  (
      flock -x 200

      CURRENT_HASH=$(md5sum "$SOURCE/package-lock.json" | cut -d' ' -f1)
      STORED_HASH=$(cat "$HASHFILE" 2>/dev/null || echo "")

      if [ "$CURRENT_HASH" != "$STORED_HASH" ] || [ ! -d "$SOURCE/node_modules" ]; then
          cd "$SOURCE" && npm ci --silent
          echo "$CURRENT_HASH" > "$HASHFILE"
      fi
  ) 200>"$LOCKFILE"

  # Sync to polecat worktree (incremental, removes stale packages)
  rsync -a --delete "$SOURCE/node_modules/" "$GT_WORKTREE_PATH/node_modules/"

This grabs a lock to serialize the polecats checks, runs npm ci in mayor/rig only if needed (using a hash check on package-lock.json), then copies it to the polecat's worktree. Claude kept wanting to use a link instead, but I was concerned the polecats might update or add packages while doing their work and that seemed like it might cause issues.

I'm hoping someone has a better solution. It's a bad time to be upgrading ram!

[DreadPirateRobertz]

Nice solution! The flock + hash-based approach is exactly right for this problem. A few observations:

Your approach is solid: Serializing npm ci with flock prevents the memory spike from parallel installs, and the hash check avoids redundant installs. This is a pattern we should probably document officially.

Alternative approaches we've seen:

1. Shared node_modules via symlink: One npm ci in the mayor/rig source, then each polecat worktree symlinks node_modules to source. Fastest, but breaks if a polecat needs different deps (rare).
2. pnpm with shared store: pnpm uses a content-addressable store, so multiple worktrees share the same physical files. Significantly reduces disk and memory usage vs npm.
3. Volume mount / bind mount: On macOS, you can bind-mount the source node_modules into each worktree. Similar to symlink but works with tools that don't follow symlinks.

For Gas Town specifically: The setup hook approach you're using is the most robust. It integrates with the polecat lifecycle naturally. If you want to upstream this as a recipe, it would be a great addition to the docs.