[React-Scripts] v3.4.1 fails to start in Docker

[timcosta]

Describe the bug

I updated from [email protected] to [email protected] and when I attempted to restart my Docker container using the new version it exited with code 0.

Recreating core-ui_web_1 ... done
Attaching to core-ui_web_1
web_1        |
web_1        | > [email protected] start /app
web_1        | > react-app-rewired start
web_1        |
web_1        | ℹ ｢wds｣: Project is running at http://172.24.0.6/
web_1        | ℹ ｢wds｣: webpack output is served from
web_1        | ℹ ｢wds｣: Content not from webpack is served from /app/public
web_1        | ℹ ｢wds｣: 404s will fallback to /
web_1        | Starting the development server...
web_1        |
core-ui_web_1 exited with code 0

This is all the logs had, but running docker-compose ps showed an exit code of 0. I tried running with/without react-app-rewired to rule that out as an issue, but the only thing that solved the issue was downgrading to ~3.3.0 again.

One weirdness I see that is different from 3.3.0 and 3.4.1 is the webpack output is served from line is blank in 3.4.1 but says / in 3.3.0.

Did you try recovering your dependencies?

I ran a fresh Docker rebuild with no cache using node:erbium as the base image to ensure there was no corruption. No luck.

Which terms did you search for in User Guide?

Docker, exit code 0.

Environment

Ran in my docker container to ensure the output is accurate.

➜  dc run web npx create-react-app --info
npx: installed 99 in 7.075s

Environment Info:

  current version of create-react-app: 3.4.1
  running from /root/.npm/_npx/6/lib/node_modules/create-react-app

  System:
    OS: Linux 4.9 Debian GNU/Linux 9 (stretch) 9 (stretch)
    CPU: (4) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  Binaries:
    Node: 12.13.1 - /usr/local/bin/node
    Yarn: 1.19.1 - /usr/local/bin/yarn
    npm: 6.12.1 - /usr/local/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    react: ^16.12.0 => 16.12.0
    react-dom: ^16.12.0 => 16.12.0
    react-scripts: ^3.4.1 => 3.4.1
  npmGlobalPackages:
    create-react-app: Not Found

Steps to reproduce

1. Install CRA with [email protected]
2. Run in docker container
3. Exits with code 0

Expected behavior

I expected the server to start.

Actual behavior

The server exited with status code 0 and no output after Starting the development server...

Reproducible demo

All CRA settings are left as their default. No CLI flags or env vars other than NODE_ENV=development.

Here's my Dockerfile:

# create base image with all packages, proper entrypoint, and directories created
FROM node:erbium AS base

# install any packages we need from apt here
RUN apt-get update \
    && apt-get install dumb-init

# set entrypoint to `dumb-init` as it handles being pid 1 and forwarding signals
# so that you dont need to bake that logic into your node app
ENTRYPOINT ["dumb-init", "--"]

# all of our code will live in `/app`
WORKDIR /app

# using the base image, create an image containing all of our files
# and dependencies installed, devDeps and test directory included
FROM base AS dependencies

COPY package*.json ./
RUN npm set progress=false \
    && npm config set depth 0 \
    && npm i
COPY ./config-overrides.js ./
COPY ./public ./public
COPY ./src ./src

# if you have any build scripts to run, like for the `templated-site` flavor
# uncomment and possibly modify the following RUN command:
# RUN npm run build
# keeping all of the bash commands you can within a single RUN is generally important,
# but for this case it's likely that we want to use the cache from the prune which will
# change infrequently.

# test running image using all of the files and devDeps
FROM dependencies AS test
USER node
ENV NODE_ENV=test
# use `sh -c` so we can chain test commands using `&&`
CMD ["npm", "test"]

FROM dependencies AS development

# expose port 3000 from in the container to the outside world
# this is the default port defined in server/manifest.js, and
# will need to be updated if you change the default port
EXPOSE 3000
CMD ["npm", "start"]

# release ready image, devDeps are pruned and tests removed for size control
FROM development AS release

RUN npm prune --production \
    rm -rf lib/**/*.spec.js

[timcosta]

After digging into the source code, I believe the issue is that

create-react-app/packages/react-scripts/config/webpackDevServer.config.js

Line 90 in 7e6d6cd

publicPath: paths.publicUrlOrPath.slice(0, -1),

combined with

create-react-app/packages/react-dev-utils/getPublicUrlOrPath.js

Line 40 in 4784997

? '/'

is causing the publicPath passed to webpack to be undefined.

[timcosta]

Update: using customize-cra i forced the publicPath to be set to / which fixed nothing being shown in the output, but i still get exit code 0.

[timcosta]

Ah, 7e6d6cd is the cause. When I set CI=true in my docker setup the container starts without issue. I believe that this should not cause the process to exit because it likely breaks running CRA in docker for many people in v3.4.0+.

[timcosta]

For anyone else that stumbles on this, instead of using docker-compose up to start your CRA service with ^3.4.0, use docker-compose run which will attach your TTY to the container and prevent the breakage.

It is impossible to run in the background now without the CI flag enabled.

[Janaka-Steph]

Same here with docker run.
Downgrading react-scripts to 3.3.0 was not a valid solution because of this other issue #8499
Downgrading react-scripts to 3.4.0 works.

[edsondewes]

Adding stdin_open: true to the docker-compose file solved the issue for me

[ivorscott]

Adding stdin_open: true or tty: true to the docker-compose file works.

stdin_open stands for interactive and tty means terminal. If you do a quick google search you find this:

7e6d6cd clearly indicates a check for interactivity.

docker run by default allocates tty. So that's why that works.
https://docs.docker.com/compose/reference/run/

Docker's documentation says: "For interactive processes (like a shell), you must use -i -t together in order to allocate a tty for the container process."

https://docs.docker.com/engine/reference/run/#foreground

[ainannan2010]

The dev environment can be started, but the production environment is blank on browser

[callain]

I am a user of CircleCI, I use a cypress orb to run my e2e tests
CI=true yarn start is not enough, the server is closed

CircleCI received exit code 0

Rollbacking to 3.4.0 make it works (I was using the 3.3.1 version before and it worked)

In my case I do not have much control over the docker being runned

[JirkaChadima]

This is (I think) the cause: #7203

Judging by this and that docker containers by default are not interactive, that is why this is currently broken and setting tty: true fixes that.

[rozacek]

I see lot of workarounds here. It's very unfortunate that step up from 3.4.0 to 3.4.1 (very minor improvement... yeap) causes that many of developers looses hours for additional reasearch to find out what stopped working - exit code 0...
Sure, adding the stdin_open: true helped but is it somewhere in documentation or some notification in logs?

[murilopucci]

Adding stdin_open: true to the docker-compose file solved the issue for me

It's working for me thanks!!

[chadacious]

upgrading to 3.4.1 with the change made from #7203 is also causing my circle ci puppeteer pipelines to break by closing the process. will start looking for workarounds.

[MHarris021]

Issue also affects kubernetes deployments based off of using the npm start command inside a docker image. an exit 0 is returned causing the pod to enter crashloopback.
adding the CI=true to the .env file fixes the issue. downgrading to 3.4.0 also resolves this behavior.

[nettelandways]

I currently have this docker-compose.yml

version: "3.8"

services:
  client:
    build: ./client
    volumes:
      - /app/node_modules
      - ./client/src:/app/src
    ports:
      - 3000:3000
    stdin_open: true
    tty: true
  backend:
    build: ./backend
    env_file: ./.env/backend
    ports:
      - 5000:5000
      - 5001:5001

And the error is still present.
I'm only spinning up client

[michalak111]

I belive tty option is not required in order to make it work, anyway are you sure your container is not starting beacuse of this?

[plaffitt]

I belive tty option is not required in order to make it work, anyway are you sure your container is not starting beacuse of this?

As stated before, either stdin_open: true or tty: true are required in order to make [email protected] working under docker using docker-compose. And I confirm that this, indeed, fixed the issue for me too.

Adding stdin_open: true or tty: true to the docker-compose file works.

stdin_open stands for interactive and tty means terminal. If you do a quick google search you find this:

7e6d6cd clearly indicates a check for interactivity.

docker run by default allocates tty. So that's why that works.
https://docs.docker.com/compose/reference/run/

Docker's documentation says: "For interactive processes (like a shell), you must use -i -t together in order to allocate a tty for the container process."

https://docs.docker.com/engine/reference/run/#foreground

[michalak111]

Yes, and that's what I meant, since @nettelandways had stdin_open: true option then tty: true isn't required.

[brentgreeff]

This has stumped me for hours. Docker is huge - please document this somewhere. - a section here would be lovely - https://create-react-app.dev/docs/getting-started

[I313006]

I am still getting the same issue as highlighted by "nettelandways" 5 days ago.

same works fine if i use docker run -it -p....... command. Server comes up.

Please suggest what to change.

[Glendragon]

Configuring docker or docker-compose to run interactively is not a solution, it's a workaround and not how I understand docker containers are intended to be run. Introducing this to your Dockerfile or docker-compose.yml will introduce unnecessary changes and may have unforeseen consequences. The issue is in react-scripts and your best bet is to stay on 3.4.0 until 3.4.2 is released where this will hopefully be fixed. A minor tweak, which was accepted in #8845, should resolve this.

[nettelandways]

For me, deleting all images and containers (used and <none>) and removing node_modules (all of this about 3 times) made it work

[Sadhr]

Hello you should add those lines and it will work fine stdin_open: true tty: true

[pekosoG]

Based on this merged code, It turns out that we have these 3 options:

• Add stdin_open: true on your docker-compose command
• Add an CI=true as an environment variable
• Downgrade your react-scripts to 3.4.0

Just remember that if you choose to downgrade your react-script version, you should verify if there's any dependency conflict because of that and you will lose any bugfix on that minor version bump

[jeremywadsack]

@pekosoG This should be resolved in master by #8845 without any of those workarounds. Are you able to verify that? That's been merged but not released yet and I don't know how to select one package from a monorepo like this directly from GitHub.

[jsrhodes15]

@pekosoG I cherry-picked #8845 and the process still exited with a 0.

[DannyM1chael]

Guys,
I had the same issue
client_1 | ℹ ｢wds｣: Project is running at http://172.28.0.3/
client_1 | ℹ ｢wds｣: webpack output is served from
client_1 | ℹ ｢wds｣: Content not from webpack is served from /usr/app/front/public
client_1 | ℹ ｢wds｣: 404s will fallback to /
client_1 | Starting the development server...
And adding to docker-compose.yml for frontend stdin_open: true helped me to solve it. Thanks!

[natlang]

I am using a fork of react-scripts so cannot downgrade. I cherry picked #8845 and the process still exited with a 0. Also removed that entire section that was added in 3.4.1 and still exiting with a 0.

if (isInteractive || process.env.CI !== 'true') {
  // Gracefully exit when stdin ends
  process.stdin.on('end', function() {
    devServer.close();
    process.exit();
  });
  process.stdin.resume();
}