Issue: Optimize Local Docker Dev Stack via Build Caching and Isolated Volumes

Description

To make local Docker/Podman testing so lightning-fast and painless that even the most skeptical developers (including Ian) willingly start using it, we need to optimize our container builds. Currently, rebuilding the local dev stack throws away the package install history, downloading the entire internet from scratch. Additionally, host node_modules compiled for Windows/macOS can clash with the Linux Alpine containers, leading to runtime failures.

We can achieve a massive developer experience (DX) upgrade by implementing local NPM caching and isolated node_modules volumes.

Proposed Optimizations

1. Persistent NPM Global Cache Volume

To avoid wasting bandwidth and time on duplicate, parallel package downloads, we can mount a shared, persistent NPM cache volume on the host or inside Docker.

By mapping a directory to /root/.npm, we cache all downloaded packages:

volumes:
  npm-cache:

services:
  init-libs:
    volumes:
      - .:/app:z
      - npm-cache:/root/.npm:z

Adding npm-cache:/root/.npm:z to all app containers ensures they share a local cache database. If a package is downloaded once, all subsequent builds/container instantiations load it instantly from the local disk cache.

2. Isolated node_modules Anonymous Volumes

When developers switch between testing on their host machines and launching docker-compose, the local node_modules (compiled for the host OS) get mounted into the Linux containers. This causes binary incompatibilities (e.g., with native Node libraries like pg or map assets).

We can resolve this by adding anonymous volumes to mask the host's node_modules folders, forcing the containers to keep their own isolated installations:

  admin:
    volumes:
      - .:/app:z
      - /app/admin/node_modules    # Anonymous volume overrides host node_modules
      - /app/libs/node_modules     # Anonymous volume overrides host libs

This prevents the container from overwriting the host files, and vice-versa, ensuring zero binary contamination.

3. Move from Dev-Mounts to Local Dockerfiles for Production Parity

Instead of spinning up dynamic Node images and compiling inside entrypoints, we should offer a secondary docker-compose.local-dist.yml or profile that builds real production-like images using our multi-stage Dockerfiles. This gives developers 100% confidence that their local code runs identically to the deployed OpenShift environment, with zero setup delta.