Failed to compile after install eslint locally (propTypes is not defined)

[trungdq88]

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

Can you reproduce the problem with latest npm?

Yes, on OSX Sierra.

Description

create-react-app test
cd test/
yarn add eslint
yarn start

Expected behavior

Should compile successfully.

Actual behavior

yarn start failed to compile, showing error: propTypes is not defined

Environment

Run these commands in the project folder and fill in their results:

1. npm ls react-scripts (if you haven’t ejected):

test@0.1.0 /Users/dinhquangtrung/Desktop/test
└── react-scripts@1.0.7

2. node -v:

v8.1.0

3. npm -v:

5.0.3

Then, specify:

1. Operating system: OSX Sierra
2. Browser and version: (any)

Reproducible Demo

Repo: https://github.com/trungdq88/create-react-app-issue
Travis Build: https://travis-ci.org/trungdq88/create-react-app-issue/builds/242429125

[trungdq88]

Seem to only happen if installed eslint 4.x. I tried with eslint 3.x and in worked. But we still need to fix this since eslint should work "inside the box", isn't it?

[shrynx]

@trungdq88 React removed PropTypes since version 15.5, see here
you can use prop-types package for it.

[trungdq88]

The problem seem to be caused by eslint-loader used the incompatible version of eslint installed outside of react-scripts (which is 4.x in my case).

The solution IMO is to config eslint-loader to use the eslint instance inside react-scripts.

Unfortunately eslint-loader have no such config, so I have submitted this: webpack-contrib/eslint-loader#181

[gaearon]

Seem to only happen if installed eslint 4.x.

If you mean that you installed eslint locally in your project, this is not really supported. I know that people do this, but we don't recommend it.

You don't need to install it locally, it will work out of the box. Installing it locally can mess up the versions, which is what probably happened.

[trungdq88]

@gaearon is this something worth fixing? I am happy to submit a PR.

The plan should be:

1. Wait for eslint-loader to add eslintPath option in the next release.
2. Add eslintPath option to eslint-loader in webpack.config.dev.js point to react-scripts/node_modules/eslint/bin/eslint.js

[gaearon]

@trungdq88 In general, yes, what you suggest sounds reasonable. I'm a bit surprised it doesn't already work like that. I'd expect eslint-loader to use Node resolution mechanism and find the right eslint.

[trungdq88]

@gaearon This build says that eslint-loader is using eslint@4.0.0 instead of the eslint packed with react-scripts, and eslint-loader is not compatible with eslint@4.0.0. That's the root cause of the bug.

[gaearon]

Can you diagnose why eslint-loader locates the wrong copy of eslint despite correct dependency from react-scripts? It's not obvious to me.

[trungdq88]

I am not sure about that. I tried to install eslint 3.x and then eslint 4.x locally in my project.

• The build fail if there is eslint 4.x in package.json.
• The build success if there iseslint 3.x in package.json.
• I found out that eslint-loader is not working with eslint 4.x.

That's how I come up with the conclusion.

[gaearon]

I understand. I am encouraging you to go down the rabbit hole and figure out why it happens. :-)

[trungdq88]

Thanks, I'll do more investigate.

It's seem weird to me that in both scenarios I had to nuke the node_modules with rm -rf node_module && yarn install && yarn start to reproduce the bug. Or else the results are totally unpredictable.

Anyway, are there test cases in this repo? I can't find them anywhere 😕

It seems like this is a yarn issue as much as a create-react-app one. I am also seeing something similar. Not exactly the same, because if you fix one of these errors and run yarn start or yarn run build again, you most likely get some more errors to fix. It goes on and on, based on some default settings that eslint seems to be incorrectly using. I went from zero warnings/errors, via yarn upgrade-interactive, to 18,700 errors, once it got as far as checking indentation levels. It also does not transpile ES7 features such as class static proptypes, presumably because eslint is falling back to some default configuration, so they are just syntax errors as far as eslint is concerned.

I have tried it with npm and npm5 and although it takes much longer, it does appear to work 100% reliably, whereas yarn fails 100% of the time. So it's something about the way yarn is building the dependency tree and satisfying dependencies that's ending up with a weird inconsistency with eslint 3/4.

[vcarel]

I got that same error on a state variable defined at class level. I guess it is the same issue, isn't it ?

export default class MyComponent extends Component {
  state = {
    open: true
  }

Failed to compile.

./src/components/MultiSelect/index.js
  Line 7:  'state' is not defined  no-undef

[gaearon]

The OP issue looks like this Yarn bug: yarnpkg/yarn#3535. I'll close in favor of it, but if you can still reproduce this after Yarn releases 0.25, please create a new issue with reproducing example.