HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Untitled Lesson

⚡ Total XP: 0|💻 backend XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Bind mounting the entire project root without protecting node_modules

// Wrong: host's node_modules overwrites the container's
volumes:
  - .:/app

// Correct: node_modules is protected by a more specific path
volumes:
  - .:/app
  - /app/node_modules

The Solution //

A bind mount like `- .:/app` syncs your host machine's node_modules (compiled for your OS/architecture, e.g. macOS ARM64) over the container's Linux-compiled node_modules built during the image's npm install, causing native modules like bcrypt to crash with an architecture mismatch error the instant the container starts. Always pair a root bind mount with an anonymous volume on node_modules specifically, so the container keeps its own correctly-compiled copy.

The Error //

Shipping a dev-only Dockerfile (with nodemon and devDependencies) to production

// Wrong: same Dockerfile everywhere, includes dev tooling in prod
RUN npm install
CMD ["npm", "run", "dev"] // runs nodemon in production!

// Correct: Dockerfile (prod) vs Dockerfile.dev (local)
// Dockerfile
RUN npm install --omit=dev
CMD ["node", "server.js"]

The Solution //

Using the same Dockerfile for both environments means production images end up bloated with test frameworks, nodemon, and dev tooling, increasing attack surface and image size unnecessarily, and sometimes even running the app via nodemon instead of a stable node process in production. Maintain separate Dockerfile / Dockerfile.dev definitions (or a multi-stage build) so production only ever installs production dependencies and runs the app directly with node.