Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Don't force "--watch" into Jest

See original GitHub issue

If you are reporting a bug, please fill in below. Otherwise feel to remove this template entirely.


I want the tests to terminate after running once. But there doesn’t seem to be any way to disable this behavior except setting the CI environment variable like: "test": "CD=true react-scripts test --env=jsdom", in package.json. I traced the source of this behavior to these lines in test.js

// Watch unless on CI
if (!process.env.CI) {

I understand that watching can be good when in the development cycle but when I want to run the tests in a pipeline or some script or git push hooks, I want to escape this mechanism.

Expected behavior

One of these

  1. Make the npm test run only once and then make another one called npm run test:watch that watches.
  2. Maybe add another package.json script called npm run test:once

Actual behavior

Tell us what actually happens.


react-scripts@0.4.1 node@6.5.0 npm@3.10.3

I can make a PR if this behavior is confirmed.

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:14
  • Comments:13 (6 by maintainers)

github_iconTop GitHub Comments

gaearoncommented, Sep 28, 2016

From your PR:

  • CI is already being handled
  • COVERAGE doesn’t really seem like a good fit for me because you can already run npm test -- --coverage as explained in User Guide, and it works in watch mode just as fine.
  • I explained why I don’t want to introduce NO_TEST_WATCH or similar in the comment above in this thread. As I also noted, I’m happy to revisit this at some point, but not now.

I understand your arguments well. I have considered each of these options (including leaving --watch in package.json) when I was integrating the test watcher. I made a choice to default to --watch unless CI is present, and I intend to stick to that choice for a while now. I appreciate your feedback and I’m happy to discuss this again in several months, but I don’t intend to change it now.

heracekcommented, May 28, 2018

Simple hack is to prevent --watch is this:

react-scripts test --watchAll=false

This works because the code detects presence of --watchAll:

if (
  !process.env.CI &&
  argv.indexOf('--coverage') === -1 &&
  argv.indexOf('--watchAll') === -1
) {
Read more comments on GitHub >

github_iconTop Results From Across the Web

Jest CLI Options
The jest command line runner has a number of useful options. You can run jest --help to view all available options. Many of...
Read more >
How to run, ignore or skip Jest tests, suites and files
Skip and ignore tests by filtering with the Jest CLI in interactive watch mode. To run the Jest CLI in interactive or watch...
Read more >
Start jest in watch mode without executing any tests
I have a lot of test files in my project, and I would like to know how can I start jest in watch...
Read more >
Modern React testing, part 2: Jest and Enzyme - Artem Sapegin
This is how I usually run Jest. Watch mode is fast enough even in large projects, where running all tests takes many minutes....
Read more >
Configuring code coverage in Jest, the right way
If there is something that should be never overlooked in any project, be it JavaScript or any other language, that's code coverage.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found