Thanks for the detailed questions. There are two separate issues here, so I'd handle them independently.

1. Memory & concurrency

NODE_OPTIONS="--max-old-space-size=4096" is a reasonable way to increase the V8 heap limit when Node is hitting OOM errors, but it doesn't necessarily prevent memory spikes by itself.

If the issue is related to npm's network concurrency, you can also limit the number of sockets used during installation:

npm ci --maxsockets=5

This can help reduce concurrent network activity and the associated memory pressure, especially in resource-constrained or isolated Docker runners.

One important caveat: make sure the container actually has enough memory available. Setting --max-old-space-size=4096 doesn't give the container 4 GB of RAM; it only allows Node to use up to roughly that amount for its V8 heap.

2. npm cache hygiene

I wouldn't recommend running:

npm cache clean --force

on every CI run. npm ci already performs integrity checks when using the npm cache, so repeatedly deleting the cache usually just increases network traffic and build time.

If you're using GitHub Actions caching, a better approach is to key the cache against the lockfile:

key: npm-cache-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}

That way, changes to package-lock.json naturally produce a new cache key instead of requiring a manual cache wipe.

For occasional maintenance, you can use:

npm cache verify

This checks the cache and removes invalid or unnecessary entries without throwing away the entire cache.

So my recommendation would be:

• OOM issues: control Node's heap size + reduce concurrency if necessary.
• CI caching: cache based on the lockfile hash.
• Routine cleanup: use npm cache verify, not npm cache clean --force.
• Avoid clearing the cache on every build unless you are specifically troubleshooting cache corruption.