Create React App 4.0 alpha caches ESLint config on first run and ignores later changes. This prevents React 17 from compiling without React import unless you modify the config before first run.

Describe the bug

When attempting to run Create React App 4.0 alpha with React 17 without an explicit React import (as 17 no longer needs it), in order to avoid ESLint errors, users are instructed to add ESLint config rules to package.json so it looks like this:

"eslintConfig": { "extends": [ "react-app", "react-app/jest" ], "rules": { "react/jsx-uses-react": "off", "react/react-in-jsx-scope": "off" } },

The problem is that currently, the initial ESLint configuration is cached when the user first runs npm start or yarn start, so if the user attempts to make this modification after running a project for the first time, the modifications will be ignored, and ESLint will continue to use the cached config, preventing compilation by throwing this error:

'React' must be in scope when using JSX react/react-in-jsx-scope

The current workaround I’ve been using, as this also affects version 3.4.3 when setting EXTEND_ESLINT=true, is to change line 345 (React Scripts 3.4.3) or line 363 (React Scripts 4.0.0-next.98) in ./node_modules/react-scripts/config/webpack.config.js from cache=true to cache=false.

Environment

System: OS: Windows 10 10.0.19041 CPU: (8) x64 Intel® Core™ i7-7700HQ CPU @ 2.80GHz Binaries: Node: 14.12.0 - C:\Program Files\nodejs\node.EXE Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD npm: 6.14.8 - C:\Program Files\nodejs\npm.CMD Browsers: Edge: 44.19041.423.0 Internet Explorer: 11.0.19041.1 npmPackages: react: ^17.0.0-rc.3 => 17.0.0-rc.3 react-dom: ^17.0.0-rc.3 => 17.0.0-rc.3 react-scripts: 4.0.0-next.98 => 4.0.0-next.98+025f2739 npmGlobalPackages: create-react-app: Not Found

Steps to reproduce

1. npx create-react-app@next --scripts-version=@next --template=cra-template@next my-app && cd my-app

2. yarn add react@17.0.0-rc.3 react-dom@17.0.0-rc.3

3. yarn start

4. CTRL-C to kill app

5. delete import React from 'react' from top of my-app/src/App.js

6. yarn start (should throw an error from eslint)

7. add the following under eslintConfig in package.json to fix the error: "rules": { "react/jsx-uses-react": "off", "react/react-in-jsx-scope": "off" }

8. run yarn start again, and the error still occurs

(It runs as expected if you modify a component after modifying ESLint config.) (It will also work again if you change cache to false in ./node_modules/react-scripts/config/webpack.config.js.) (The behavior is identical when using npm instead of yarn.)

Expected behavior

I expect the app to run normally.

Actual behavior

Browser output:

Failed to compile.

./src/App.js Line 6:5: ‘React’ must be in scope when using JSX react/react-in-jsx-scope Line 7:7: ‘React’ must be in scope when using JSX react/react-in-jsx-scope Line 8:9: ‘React’ must be in scope when using JSX react/react-in-jsx-scope Line 9:9: ‘React’ must be in scope when using JSX react/react-in-jsx-scope Line 10:16: ‘React’ must be in scope when using JSX react/react-in-jsx-scope Line 12:9: ‘React’ must be in scope when using JSX react/react-in-jsx-scope

Reproducible demo

N/A - A fresh install would fix it, as the problem is in the cached files, and I can’t reproduce that without uploading the entire node_modules directory.

The main problem is that this bug will cause an almost fresh application to fail, and the user won’t have any idea what caused it.

This is also a problem with using EXTEND_ESLINT on the current stable version of CRA. But I think this is a much more significant problem, because extending ESLint right now is an experimental feature, and it isn’t expected to work perfectly.

But with this, if someone tries to add React 17 to a project and use its intended features, it will fail to compile unless they modify package.json before the first run, and they’ll probably just think it’s buggy, as there won’t be any indication why it’s failing.

[leojh]

@robertwt7 did you end up fixing it? Running into this myself.

[AndrewHawes]

I realized I was wrong about what was actually happening. The ESLint config isn’t itself being cached, it’s just the result of linting is being cached. So if you modify a src file after modifying the config, it will use the new ESLint config, but it will ignore config changes if you only change the config. It also seems to revert and used the cached result if you change the file back to a state in which it was already linted. So if I remove the import line from App.js, run it, then modify the config to turn those errors off, it will still have the same errors, but if I change App.js again, it will relint it.

I think this will cause a lot of confusion. I don’t really know if this could be considered a CRA issue now. Maybe it’s an issue with eslint-loader or webpack. But I think maybe caching should be turned off if there isn’t a way to force ESLint to check its own config, as anyone who encounters an error then tries to fix it by editing the config will probably end up frustrated.