<p>Depend of life cycle of you app, because Node libraries and dependences change or end life to obsolet, so if you app constant change version to deploy, you can use <a href="https://docs.docker.com/engine/reference/commandline/tag/" rel="nofollow noreferrer">docker tag</a> for describe version or time when it build image, is a good practice, so Dockerfile shall copy package.json, and too look when you need change image source OS, by example change ubuntu linux to alpine , many dependences or how to install "npm" and dependences for node, a example:</p>

<pre><code>  FROM alpine:3.8

# Update
RUN apk add --update nodejs nodejs-npm

# Install app dependencies
COPY package.json /src/package.json

RUN cd /src; npm install

# Bundle app source
COPY . /src

EXPOSE 5000
CMD ["node","src/index.js"]
</code></pre>

<p>well , hope it help you</p>

CC BY-SA 4.0
2018-09-11T23:37:05.893Z
2018-09-11T23:37:05.893Z
Soleil
<p>Assuming this is a production <code>Dockerfile</code>, the boilerplate configuration for a Nodejs type of application would look like this:</p>

<pre><code>FROM node:alpine as builder
WORKDIR '/app'
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
</code></pre>

<p>or like this:</p>

<pre><code>FROM node:alpine
WORKDIR "/app"
COPY ./package.json ./
RUN npm install
COPY . .
CMD ["npm", "run", "start"]
</code></pre>

<p>and if you involve Nginx, you may additionally have a couple of lines that would look something like this:</p>

<pre><code>FROM nginx
EXPOSE 80
COPY --from=builder /app/build /usr/share/nginx/html
</code></pre>

<p>So now you have a couple of answers with a few variations of how you could write out the production ready <code>Dockerfile</code>.</p>

CC BY-SA 4.0
2019-03-14T00:26:03.140Z
2019-03-14T00:26:03.140Z
Daniel
<p>I would like to prepare a Docker image for a nodejs project. The developers use package.json to list their node module dependencies. I would like to prepare the Docker image (as base on the Dockerfile), with most of the node_modules already installed "globally" on the image. </p>

<p>Is there a best practice to prepare nodejs images?</p>

<docker><dockerfile><node.js>
Preinstall packages for a nodejs Docker Image according to package.json
orberkov
# Preinstall packages for a nodejs Docker Image according to package.json

(Asked by: username_0 on 2018-09-11)

I would like to prepare a Docker image for a nodejs project. The developers use package.json to list their node module dependencies. I would like to prepare the Docker image (as base on the Dockerfile), with most of the node\_modules already installed "globally" on the image.

Is there a best practice to prepare nodejs images?

**Tags:** docker, dockerfile, node.js


---

## 2 answers

### Answer by username_1 on 2018-09-11. Score: 1

Depend of life cycle of you app, because Node libraries and dependences change or end life to obsolet, so if you app constant change version to deploy, you can use docker tag for describe version or time when it build image, is a good practice, so Dockerfile shall copy package.json, and too look when you need change image source OS, by example change ubuntu linux to alpine , many dependences or how to install "npm" and dependences for node, a example:
  FROM alpine:3.8

# Update
RUN apk add --update nodejs nodejs-npm

# Install app dependencies
COPY package.json /src/package.json

RUN cd /src; npm install

# Bundle app source
COPY . /src

EXPOSE 5000
CMD ["node","src/index.js"]

well , hope it help you


---

### Answer by username_2 on 2019-03-14. Score: 1

Assuming this is a production Dockerfile, the boilerplate configuration for a Nodejs type of application would look like this:
FROM node:alpine as builder
WORKDIR '/app'
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

or like this:
FROM node:alpine
WORKDIR "/app"
COPY ./package.json ./
RUN npm install
COPY . .
CMD ["npm", "run", "start"]

and if you involve Nginx, you may additionally have a couple of lines that would look something like this:
FROM nginx
EXPOSE 80
COPY --from=builder /app/build /usr/share/nginx/html

So now you have a couple of answers with a few variations of how you could write out the production ready Dockerfile.


---

