0

I have a simple ReactJS application, which is deployed to AWS EB, with Docker.

My Dockerfile looks like this:

FROM node:12.2.0-alpine as build
WORKDIR /app
ENV PATH /app/node_modules/.bin:$PATH
ENV REACT_APP_VAR val
ENV REACT_APP_VAR2 val2
COPY package.json /app/package.json
RUN npm install --silent --unsafe-perm --max-old-space-size=1024
RUN npm install react-scripts@3.0.1 -g --silent --max-old-space-size=1024
COPY . /app
RUN npm --max-old-space-size=1024 run build

FROM nginx:1.16.0-alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

I have been using the same docker file for months by now. Today suddenly, I start build errors like below on AWS EB Logs (and got the same error while trying to build the image on my local)

Step 21/26 : RUN npm --max-old-space-size=1024 run build
 ---> Running in 879c536e7f65

> frontend@0.1.0 build /app
> react-scripts build

Creating an optimized production build...
Failed to compile.

./src/components/file.js
  Line 187:5:  'SomeCustomButtonRef' is not defined  no-undef

Search for the keywords to learn more about each error.


npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! frontend@0.1.0 build: `react-scripts build`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the frontend@0.1.0 build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2021-02-23T10_25_14_373Z-debug.log

This error started happening today, out of sudden.

When I run the command npm --max-old-space-size=1024 run build on my local w/o any Docker related commands, it runs fine and builds.

I have tried to change the node version tag in Dockerfile, but the result was the same. I have tried to comment out the part where it breaks (it is simply SomeCustomButtonRef = React.createRef()) but then docker build command breaks with more lines ABC is not defined no-undef in some other file.

Any one had similar issue with react + docker, especially like out of sudden it starts breaking the builds ?

David Maze
  • 130,717
  • 29
  • 175
  • 215
denizdurmus
  • 1,289
  • 1
  • 13
  • 39
  • That looks like an issue with a build tool your `package.json` invokes, not Node or Docker. If you also `COPY package.lock` into the image before you `RUN npm install`, you'll get fixed versions of dependencies; does including that file help (by using a slightly older version of the build toolchain)? – David Maze Feb 23 '21 at 11:03
  • @DavidMaze you mean package-lock.json? – denizdurmus Feb 23 '21 at 12:00
  • Yes. (I think I was thinking of `yarn.lock`, which is the `yarn` equivalent.) – David Maze Feb 23 '21 at 12:03
  • @DavidMaze Copying package-lock.json worked on my local, will try to deploy to EB. One thing I realise, an older branch works ok without adding package-lock.json to Dockerfile, with identical content. Could it be that some files are not being tracked, hence causing some sort of dirty cache/files somewhere? – denizdurmus Feb 23 '21 at 12:22
  • It works on EB as well, with the package-lock.json added. Can you reply the question so I can make it as answer? – denizdurmus Feb 24 '21 at 03:54
  • @denizdurmus Could it be the same issue as this - https://stackoverflow.com/questions/66345964/state-is-not-defined-no-undef/66346199#66346199 – Lakshya Thakur Feb 24 '21 at 11:05

1 Answers1

1

npm has two files that explain what packages need to be installed. package.json lists out the package and potentially broad version constraints; package-lock.json has extremely specific versions of the packages that are used in a specific build. When you do the initial install inside your Dockerfile, you should copy both of these files into the image:

COPY package.json package-lock.json .
RUN npm ci

The problem you describe doesn't sound like a problem with Docker or Node itself, but one of the packages that's being used in the npm run build sequence. Since the original Dockerfile didn't include the package-lock.json file, if some involved package updated from version 1.2.3 to 1.2.4 and the newer version had an issue, everything would look consistent until the build eventually failed. Including the lock file keeps you on a known-working build chain.

David Maze
  • 130,717
  • 29
  • 175
  • 215