title: Clean AND practical way to handle node_modules in a Dockerized Node.js dev environment?
body: <p>I have been trying to dockerize (both for development and later for production) a MERN stack application recently, and the interaction between Node.js (more especially the node_modules) and Docker kind of puts me off. In the whole question, I will designate the computer that is used for development as the "host machine".</p>
  
  <h2>TL;DR</h2>
  
  <p>Is there a way that is not too impractical to Dockerize a Node.js app without mounting the node_modules folder of your host machine to the container when developing ?</p>
  
  <h2>My attempted approaches (and why none of them satisfies me)</h2>
  
  <p>I can think of 3 big advantages of using Docker (and its docker-compose utility) for development (I will refer to these as <strong>points 1, 2 and 3</strong>) :</p>
  
  <ol>
  <li>It makes it easy to setup the dev environment on new machines, or integrate new members in the project, in that you do not have to manually install anything besides Docker itself.</li>
  <li>The app is easy to run for debugging while developing (just a quick <code>docker-compose up</code> and the db, the backend and the frontend are up and running).</li>
  <li>The runtime environment is consistent across all machines and the app's final production environment, since a Docker container is kind-of its own small Linux virtual machine.</li>
  </ol>
  
  <p>The first 2 points pose no problem when dockerizing a Node.js application ; however I feel like the third one is harder to achieve in a dev environment because of how the dependencies work in Node, and its node_modules functioning. Let me explain :</p>
  
  <p>This is my simplified project folder structure :</p>
  
  <pre><code>project
  │   docker-compose.yml
  │
  └───node-backend
  │   │   Dockerfile
  │   │   package.json
  │   │   server.js
  │   │
  │   └───src
  │   │   │   ...
  │   │
  │   └───node_modules
  │       │   ...
  │
  └───react-frontend
      │   ...
  </code></pre>
  
  <p>From what I have tried and what I have seen in articles and tutorials on the internet, there are basically 3 approaches to developing Node.js with Docker.
  In all 3 approaches, I assume I am using the following Dockerfile to describe the image of my app :</p>
  
  <pre><code># node-backend/Dockerfile
  FROM node:lts-alpine
  WORKDIR /usr/src/app
  
  COPY package*.json ./
  RUN npm install
  
  COPY . ./
  
  EXPOSE 8000
  CMD [ "npm", "start" ]
  </code></pre>
  
  <ul>
  <li><h3>Approach 1 : Quick and dirty</h3>
  
  <p>When developing, mount your host machine's whole code folder (including the node_modules) to your container. The <code>docker-compose.yml</code> file typically looks like this (not including the database or the react app config for clarity) :</p>
  
  <pre><code># ./docker-compose.yml
  version: "3"
  services:
      backend:
          build: ./node-backend/
          ports:
              - 8000:8000
          volumes:
              - ./node-backend:/usr/src/app
  </code></pre>
  
  <p>This approach is the easiest to setup and use for development : code is synchronized between the host and the container, hot-reloading (with <em>nodemon</em> for example) works, dependencies are synchronized between host and container (no need to rebuild the container at each <code>npm install some-module</code> on the host machine).</p>
  
  <p>However, it doesn't respect <strong>point 3</strong> : since the host machine's node_modules are also mounted to the container, they may contain some platform-specific parts (for example <em>node-gyp</em> addons) that were compiled for your host machine's OS (in my case, macOS or Windows) and not for the container's OS (Alpine Linux).</p></li>
  <li><h3>Approach 2 : Cleaner but annoying to install new dependencies</h3>
  
  <p>Mount the host machine's source code folder, but this time create a volume (named or anonymous) that will hold the container's node_modules, preventing them from being hidden by the host machine's node_modules.</p>
  
  <pre><code># ./docker-compose.yml
  version: "3"
  services:
      backend:
          build: ./node-backend/
          ports:
              - 8000:8000
          volumes:
              - ./node-backend:/usr/src/app
              - /usr/src/app/node_modules
  </code></pre>
  
  <p>With this approach, <strong>point 3</strong> is now respected : we ensure that the node_modules folder used by the container in development was created <strong>specifically for the container</strong>, and thus contains the appropriate platform-specific code.</p>
  
  <p>However, installing new dependencies is a pain :</p>
  
  <ul>
  <li>Either you run your <code>npm install</code>s directly in the container (using <code>docker exec</code>), but then the dependencies are not installed on your host machine unless you do it manually each time. It's important to also have them installed locally for the IDE (VSCode in my case) to provide auto-completion, linting, avoid "missing module" warnings...</li>
  <li>Either you run your <code>npm install</code>s on your host machine but you have to rebuild your Docker image each time so that the node_modules of the container are up-to-date, which is time-consuming.</li>
  </ul></li>
  <li><h3>Approach 3 : Probably the cleanest, but harder to setup</h3>
  
  <p>The final approach would be to develop directly <strong>within</strong> the container, which means that there is no host mounting to do, you just have to create a volume (let's make it named this time, but I think anonymous may work too ?) so that changes to your code and node_modules are persistent. I haven't tried this approach yet so I am not sure what the <code>docker-compose.yml</code> file would look like, but probably something among those lines :</p>
  
  <pre><code># ./docker-compose.yml
  version: "3"
  services:
      backend:
          build: ./node-backend/
          ports:
              - 8000:8000
          volumes:
              - backend-data:/usr/src/app
  volumes:
      backend-data:
  </code></pre>
  
  <p>This approach also respects <strong>point 3</strong>, but remote development within a container is harder to setup than regular development on your host machine (although VSCode apparently <a href="https://code.visualstudio.com/docs/remote/containers" rel="noreferrer">simplifies the process</a>). Also, source code version-control (<em>i.e.</em> using Git) seems a bit annoying to do, since you would have to pass your host machine's SSH identification onto your container for it to be allowed to access your remote repo.</p></li>
  </ul>
  
  <h2>Conclusion</h2>
  
  <p>As you can see, I am yet to find an approach that combines all of the advantages I am looking for. I need an approach that is easy to setup and to use in development ; that respects <strong>point 3</strong> because it is an important aspect of the philosophy and purpose of containerization ; that doesn't make synchronizing node_modules between the container and the host machine a headache, while preserving all of the IDE's functionalities (Intellisense, linting, etc.).</p>
  
  <p>Is there something I am completely missing on ? What are you guys' solutions to this problem ?</p>